Файлы сохраняемости Casper-rw не работают с 20.04
Я только что заметил, что постоянные файлы casper-rw не работают с Ubuntu 20.04, когда загружается из файла ISO .
Постоянные разделы снова работают, однако постоянные разделы не работают с «постоянным путем», и для каждого USB-накопителя разрешен только один постоянный раздел.
Это означает, что многозагружаемый многопользовательский USB-накопитель больше не возможно использовать файлы ISO. fs.file-макс = 99999999 kernel.pid_max = 4194304 kernel.threads-макс = 99999999 kernel.sem = 32768 1073741824 2000 32768 kernel.shmmni = 32768 kernel.msgmni = 32768 ...
# cat /etc/sysctl.conf
fs.aio-max-nr=99999999
fs.file-max=99999999
kernel.pid_max=4194304
kernel.threads-max=99999999
kernel.sem=32768 1073741824 2000 32768
kernel.shmmni=32768
kernel.msgmni=32768
kernel.msgmax=65536
kernel.msgmnb=65536
vm.max_map_count=1048576
# cat /etc/security/limits.conf
* soft core unlimited
* hard core unlimited
* soft data unlimited
* hard data unlimited
* soft fsize unlimited
* hard fsize unlimited
* soft memlock unlimited
* hard memlock unlimited
* soft nofile 1048576
* hard nofile 1048576
* soft rss unlimited
* hard rss unlimited
* soft stack unlimited
* hard stack unlimited
* soft cpu unlimited
* hard cpu unlimited
* soft nproc unlimited
* hard nproc unlimited
* soft as unlimited
* hard as unlimited
* soft maxlogins unlimited
* hard maxlogins unlimited
* soft maxsyslogins unlimited
* hard maxsyslogins unlimited
* soft locks unlimited
* hard locks unlimited
* soft sigpending unlimited
* hard sigpending unlimited
* soft msgqueue unlimited
* hard msgqueue unlimited
# cat /etc/systemd/logind.conf
[Login]
UserTasksMax=infinity
# free -g
total used free shared buff/cache available
Mem: 117 5 44 62 67 48
Swap: 15 8 7
# df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 194G 121G 74G 63% /
# cat /proc/meminfo
MemTotal: 123665416 kB
MemFree: 90979152 kB
MemAvailable: 95376636 kB
Buffers: 72260 kB
Cached: 25964076 kB
SwapCached: 0 kB
Active: 8706568 kB
Inactive: 22983044 kB
Active(anon): 7568968 kB
Inactive(anon): 18871224 kB
Active(file): 1137600 kB
Inactive(file): 4111820 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 16777212 kB
SwapFree: 16777212 kB
Dirty: 20 kB
Writeback: 0 kB
AnonPages: 5653128 kB
Mapped: 185100 kB
Shmem: 20786924 kB
KReclaimable: 281732 kB
Slab: 541000 kB
SReclaimable: 281732 kB
SUnreclaim: 259268 kB
KernelStack: 34384 kB
PageTables: 93216 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 78609920 kB
Committed_AS: 63750908 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 46584 kB
VmallocChunk: 0 kB
Percpu: 18944 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 0 kB
DirectMap4k: 183484 kB
DirectMap2M: 5058560 kB
DirectMap1G: 122683392 kB
And for the user account used to run the scripts:
$ ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1048576
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) unlimited
real-time priority (-r) 0
stack size (kbytes, -s) unlimited
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
Пока что
./somescript.sh: fork: retry: Resource temporarily unavailable
Сервер имеет среднюю нагрузку (~ 20 атм средней нагрузки) и использует множество скриптов , которые выполняют разветвление (т. Е. $ (comecode) внутри много скриптов). Сервер (экземпляр облака Google) имеет 16 ядер и 128 ГБ оперативной памяти с диском tmpfs 100 ГБ и подкачкой 16 ГБ. Даже когда ЦП, память и подкачка менее 50% используют показанные сообщения.
Трудно поверить, что он достигнет любого из этих и без того высоких верхних пределов. Я подозреваю, что есть некоторые другие настройки, которые влияют на это.
Что еще можно настроить, чтобы избежать этой fork: retry: Ресурс временно недоступен проблема?
1 ответ
После дополнительной отладки я наконец нашел ответ. Ответ кажется очень ценным в том, что другие могут столкнуться с этим. Это также может быть ошибка в Ubuntu (TBD)
Мои сценарии внесли следующее изменение (в сценарии) в разных местах:
ulimit -u 20000 2>/dev/null
Число 20000 будет варьироваться от 2000 до 40000 в зависимости от сценарий / ситуация.
То, что, таким образом, происходит, так это то, что, как только несколько процессов каким-то образом «максимально» увеличили максимальное количество открытых файлов (1048576) - что, казалось бы, легко сделать, например, только с ограниченным числом скрипты - умножаются каждый раз на соответствующие настройки ulimit. Результатом было то, что на максимуме было запущено около 2000-2200 потоков.
Я удалил все настройки ulimit -u , и теперь не получаю никакой вилки : retry: