Если вы увеличили /proc/sys/kernel/pid_max
(, выполнив cat 100000 > /proc/sys/kernel/pid_max
, например ), это значение вступает в силу сразу же, нет необходимости в перезагрузке. Я никогда не пытался уменьшить его(*).
Вы можете проверить это следующим (способом, который несколько уродлив, его нельзя делать на производственной машине):
i=0 ; while [ $i -lt 10000] ; do (echo $i > /dev/null); ((i++)); done; ps ax | grep AnythingUnlikelyToBeUsedAlready
(echo $i > /dev/null)
предназначен только для создания нового pid на каждой итерации. 10000 было удобно в моем тестовом случае, но вы можете настроить его. Здесь он зацикливается при запуске #3, поскольку я ранее установил свой pid_max
, как описано выше :
.
shlublu:~$ i=0 ; while [ $i -lt 10000 ] ; do (echo $i > /dev/null); ((i++)); done; ps ax | grep AnuthingUnlikelyToBeUsedAlready
86880 pts/0 S+ 0:00 grep --color=auto AnuthingUnlikelyToBeUsedAlready
shlublu:~$ i=0 ; while [ $i -lt 10000 ] ; do (echo $i > /dev/null); ((i++)); done; ps ax | grep AnuthingUnlikelyToBeUsedAlready
96882 pts/0 S+ 0:00 grep --color=auto AnuthingUnlikelyToBeUsedAlready
shlublu:~$ i=0 ; while [ $i -lt 10000 ] ; do (echo $i > /dev/null); ((i++)); done; ps ax | grep AnuthingUnlikelyToBeUsedAlready
7246 pts/0 S+ 0:00 grep --color=auto AnuthingUnlikelyToBeUsedAlready
shlublu:~$ i=0 ; while [ $i -lt 10000 ] ; do (echo $i > /dev/null); ((i++)); done; ps ax | grep AnuthingUnlikelyToBeUsedAlready
17260 pts/0 S+ 0:00 grep --color=auto AnuthingUnlikelyToBeUsedAlready
shlublu:~$ i=0 ; while [ $i -lt 10000 ] ; do (echo $i > /dev/null); ((i++)); done; ps ax | grep AnuthingUnlikelyToBeUsedAlready
27262 pts/0 S+ 0:00 grep --color=auto AnuthingUnlikelyToBeUsedAlready
Но если вы перезапустите после этого, вы увидите, что /proc/sys/kernel/pid_max
будет восстановлено значение по умолчанию(32768, обычно ).
Чтобы ваши настройки сохранялись при перезапусках, вы должны отредактировать /etc/sysctl.conf
и установить kernel.pid_max
соответствующим образом.
Например:
kernel.pid_max = 100000
Предупреждение:pid_max
имеет ограничения , которые зависят от вашей системы. Значение, которое вы определяете, должно находиться в этих пределах.
(*)но @peterh сделал, и это работает, очевидно, см. комментарии .
Предположим, что ваши данные находятся в файле с именемfile
:
$ sort -t '|' -k3,3r -k6,6r file | sort -t '|' -u -k1,1
150096747|000000645048|2019-10-17|2019-10-17|1265457733|2019-01-13
150098517|000000637002|2019-10-20|2019-10-19|1265457733|2019-01-14
150098523|000000645194|2019-10-18|2019-10-16|1265457733|2019-01-13
150098554|000000645194|2019-10-18|2019-10-16|1265457733|2019-01-13
150098555|000000645194|2019-10-18|2019-10-16|1265457733|2019-01-13
Это сначала сортирует данные в 3-м|
-поле с разделителями в обратном порядке (сначала самые последние даты ). Для одинаковых дат для сортировки используется 6-е поле.
Промежуточный результат первого вызова sort
выглядит следующим образом:
150098517|000000637002|2019-10-20|2019-10-19|1265457733|2019-01-14
150098517|000000635671|2019-10-20|2019-10-20|1265457733|2019-01-13
150098517|000000645047|2019-10-20|2019-10-18|1265457733|2019-01-12
150098517|000000601706|2019-10-19|2019-10-10|1265457733|2019-01-13
150098523|000000645194|2019-10-18|2019-10-16|1265457733|2019-01-13
150098554|000000645194|2019-10-18|2019-10-16|1265457733|2019-01-13
150098555|000000645194|2019-10-18|2019-10-16|1265457733|2019-01-13
150096747|000000645048|2019-10-17|2019-10-17|1265457733|2019-01-13
150098523|000000645194|2019-10-14|2019-10-16|1265457733|2019-01-13
Результат этого затем сортируется по первому полю, при этом удаляются строки, которые являются дубликатами с точки зрения этого первого поля. Поскольку данные, поступающие в эту вторую сортировку, сортируются по датам в 3-м и 6-м полях, строки, которые отбрасываются как дубликаты, будут иметь более ранние даты.