Сzsh
:
rm -f /usr/local/bin(@e'{[[ $REPLY:P = /usr/local/texlive/* ]]}')
$REPLY:P
полностью разрешает путь к свободной символической ссылке -, поэтому, предполагая, что /usr/local/texlive
сам по себе свободен от символической ссылки, он удалит все файлы, которые после разрешения символической ссылки находятся под /usr/local/textlive
, что будет включать ссылки на /usr/local/texlive/foo
, но также на ../texlive/bar
, или на /usr/./local/texlive/whatever
, или на /some/other/symlink
, который сам по себе является символической ссылкой, указывающей на /usr/local/texlive
и т. д.
Как предложил Уолтинатор в комментарии к вашему вопросу, вы можете запустить свой процесс с помощью сценария оболочки. Этот сценарий может заблокировать ожидание завершения вашего процесса, а затем проверить статус выхода, чтобы получить некоторое представление о режиме сбоя.
Обычно, если процесс завершается сигналом, состояние существования равно 128 плюс номер сигнала. Например, если кто-то сделал kill -9
для процесса, тогда статус выхода будет 137 (128 + 9 = 137 ).
Например, вот скрипт, который запускает вашу команду и печатает сообщение, если он завершился в ответ на сигнал:
#!/bin/bash
$JAVA_HOME/bin/java \
-verbose \
-classpath '../../lib/*:.:./config' com.xxx.xxx.core.xxxxApp instance:$INSTANCE
rc=$? # The $? variable has the exit status of the previous command
if [[ ${rc} -gt 128 ]]; then
printf "Process terminated with signal %d\n" $((rc - 128))
fi
Теперь, если я использую kill -9
для завершения процесса java
, я получаю:
Process terminated with signal 9
Похоже, что ядро убивает процесс из-за некоторых проблем, например, если процесс потребляет слишком много памяти, то ядро Out of Memory(OOM )killer автоматически уничтожит процесс-нарушитель. Вы можете убедиться, проверив журналы на наличие журналов ошибок, связанных с ядром :
.egrep -i 'killed process' /var/log/messages
или
egrep -i -r 'killed process' /var/log
Я предлагаю проверить системные журналы и просмотреть журналы, связанные с процессом выполняемой вами Java-программы.
dmesg | grep -i kill
Это, например, отображает журналы, связанные с убийствами, чтобы проверить полные журналы, которые вы можете использовать:
dmesg | less
системные журналы предоставляют вам подробную информацию о том, почему процесс был убит, проблема с памятью или что-то другое.
Если кто-то убивает этот процесс, должен быть суперпользователь, вы можете проверить /var/log/auth.log
для команды kill