При буферизации вывода, можно отправить его в column
:
#!/bin/bash
TMP=/tmp/output-buffer
echo "">$TMP
ls -l | while read response
do
words=`echo $response | wc -w`
case "$words" in
9) echo $response | cut -d " " -f9 >>$TMP
;;
11) echo $response | cut -d " " -f9-11 >>$TMP
;;
esac
done
cat $TMP | column
rm $TMP
Согласно документации Nginx, SIGQUIT выполнит «плавное завершение работы», а SIGTERM выполнит «быстрое завершение работы». По крайней мере, начиная с версии 1.8.0, Nginx будет оставлять устаревшие сокеты домена UNIX при остановке с помощью сигнала SIGQUIT . Однако сокеты домена UNIX правильно удаляются при использовании сигнала SIGTERM .
Сценарий службы Nginx /etc/init.d/nginx
, предоставленный PPA nginx / stable
, отправляет SIGQUIT в Nginx, когда он останавливается с помощью sudo service nginx stop
или restart
. Чтобы исправить сценарий, измените строку:
STOP_SCHEDULE="${STOP_SCHEDULE:-QUIT/5/TERM/5/KILL/5}"
To:
STOP_SCHEDULE="${STOP_SCHEDULE:-TERM/5/KILL/5}"
Однако служебный сценарий Nginx из репозитория Ubuntu уже использует SIGTERM вместо SIGQUIT и не требует быть модифицированным.
Я не думаю, что это связано с плавным или быстрым завершением работы, поскольку я использовал плавную остановку , а я ' м тоже есть эта проблема.
В моем случае я заметил, возможно, связанную / дополнительную проблему, что nginx
продолжает попытки подключиться к давно не функционирующему сокету, даже после того, как сокет и все его вызовы были удалены (по крайней мере, что касается файлов, которые я намеренно создал или изменил).
Размещение сокета в / tmp
кажется обходным путем, который позволит избежать этой проблемы, но я все еще не могу избавиться от призрачных сокетов, которые были ранее созданы в другом месте.
Так что я даже не понимаю, откуда взялась проблема. В какой момент nginx
решил запомнить сокет навсегда, и есть ли способ сбросить его?
В качестве быстрого исправления в 16.04 Xenial я смог просто удалить проблемный сокет:
sudo systemctl stop nginx
sudo rm /var/run/serve-files.socket
sudo systemctl start nginx