Я использую свой собственный сервис, назовем его «foo.service». Это процесс Python-пулеметчика, который регистрирует несколько вещей.
Раньше я мог просматривать журнал в реальном времени, используя journalctl -u <service> -f
но теперь журнал, кажется, застрял в каких-то прошлых журналах. Когда я использую systemctl status <service>
хотя он показывает последние журналы. Итак, мой журнал работает, но journalctl, похоже, завис и не показывает никаких обновлений.
Пример:
journalctl -u foo.service -f
Nov 25 16:19:09 <name> systemd[1]: Started Instance to load up the program and its endpoints.
Nov 25 16:19:09 <name> gunicorn[28267]: 2019-11-25 16:19:09,844 [INFO]: Connecting to localhost:9773
Nov 25 16:19:09 <name> gunicorn[28267]: 2019-11-25 16:19:09,845 [INFO]: Connecting to localhost:9771
Nov 25 16:19:09 <name> gunicorn[28267]: 2019-11-25 16:19:09,846 [INFO]: Connected
Nov 25 16:19:09 <name> gunicorn[28267]: 2019-11-25 16:19:09,846 [INFO]: Connected
systemctl status foo.service
Nov 26 11:39:53 <name> systemd[1]: Started Instance to load up the program and its endpoints.
Nov 26 11:39:53 <name> gunicorn[29117]: 2019-11-26 11:39:53,458 [INFO]: Connecting to localhost:9773
Nov 26 11:39:53 <name> gunicorn[29117]: 2019-11-26 11:39:53,459 [INFO]: Connecting to localhost:9771
Nov 26 11:39:53 <name> gunicorn[29117]: 2019-11-26 11:39:53,460 [INFO]: Connected
Nov 26 11:39:53 <name> gunicorn[29117]: 2019-11-26 11:39:53,460 [INFO]: Connected
Последний - это только что созданный журнал, поэтому он работает как шарм, но, насколько я понимаю, journalctl, похоже, также обновляется. Это действительно работало в прошлом, я столкнулся с этими проблемами позавчера.
Я попытался перезапустить journalctl, но это не сработало.
Заранее спасибо.
РЕДАКТИРОВАТЬ: Когда я перезапускаю свою службу, я замечаю, что Gunicorn выдал исключение, когда я смотрю на состояние службы systemctl, я не могу прокрутить вверх, поэтому я не знаю, в чем причина ошибки (статус systemctl):
Nov 26 15:08:27 <name> gunicorn[29390]: self.log.info("Shutting down: %s", self.master_name)
Nov 26 15:08:27 <name> gunicorn[29390]: File "/opt/my-program/venv/lib/python3.5/site-packages/gunicorn/glogging.py", line 271, in info
Nov 26 15:08:27 <name> gunicorn[29390]: self.error_log.info(msg, *args, **kwargs)
Nov 26 15:08:27 <name> gunicorn[29390]: Message: 'Shutting down: %s'
Nov 26 15:08:27 <name> gunicorn[29390]: Arguments: ('Master',)
Nov 26 15:08:27 <name> systemd[1]: Started Instance to load up the program and its endpoints.
Мой файл конфигурации foo.service:
[Unit]
Description=Instance to load up the program and its endpoints
After=network.target
[Service]
User=root
Group=www-data
WorkingDirectory=/opt/my-program/my-program-thing
Environment="PATH=/opt/my-program/venv/bin"
ExecStart=/opt/my-program/venv/bin/gunicorn --workers 1 --threads 12 --bind unix:foo.sock -m 007 app:app --bind 0.0.0.0:8085 --access-logfile '/var/log/foo.info.log' --error-logfile '/var/log/foo.err.log'
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
Попробуйте добавить эти строки в свой служебный файл в теге [Service].
StandardOutput=journal
StandardError=journal
Затем выполните systemctl daemon-reload, затем выполните systemctl restart your_service.service
Я редактирую ответ, чтобы другие легко его увидели. Проблема заключалась в нехватке места в файловой системе / var, поэтому journalctl не мог сохранять журналы на диск и потом читать, поэтому была разница между статусом systemctl и journalctl -fu.