Действительно ли возможно изменить то, что тег systemd управляемый сервис использует для входа? Например, моя служба поддержки report-daemon.service
определенный как
# ...
[Service]
ExecStart=/usr/bin/php # ...
# ...
обнаруживается как php
вместо report-daemon
(это, кажется, выводит тег из ExecStart
)
$ sudo journalctl --unit report-daemon
# ...
May 30 16:26:11 delta php[994]: Found 0 new revisions for Ctytn4a6zjw
May 30 16:26:12 delta php[994]: Found 0 new revisions for efE8xuvUjAo
# ...
Страница справочника не перечисляет опции для установки этого в файле единицы. Действительно ли возможно изменить тег где-нибудь?
Обновление 1: подробный вариант будет отображаться в длинном формате и, таким образом, включает UNIT:
[root@localhost]# journalctl --unit newnginx -o verbose
-- Logs begin at Sun 2015-04-05 10:36:30 BST, end at Mon 2015-06-01 08:17:58 BST. --
Sun 2015-05-31 10:27:38.344553 BST [s=4cc44a9cf9344c948fd4716fe024439e;i=3198;b=be3381af5b1d4743a4ccc1e346eab405;m=1548bfaf08;t=5175d51fadf41;x=eb6bb8ee2b2be47e]
PRIORITY=6
_UID=0
_GID=0
_BOOT_ID=be3381af5b1d4743a4ccc1e346eab405
_MACHINE_ID=9619293167aa4f76b45b745e9f4e8935
_HOSTNAME=localhost.localdomain
_CAP_EFFECTIVE=1fffffffff
_SYSTEMD_CGROUP=/
SYSLOG_FACILITY=3
SYSLOG_IDENTIFIER=systemd
_TRANSPORT=journal
_PID=1
_COMM=systemd
_EXE=/usr/lib/systemd/systemd
_CMDLINE=/usr/lib/systemd/systemd --system --deserialize 21
_SELINUX_CONTEXT=system_u:system_r:init_t:s0
CODE_FILE=src/core/unit.c
CODE_LINE=1115
CODE_FUNCTION=unit_status_log_starting_stopping_reloading
MESSAGE_ID=7d4958e842da4a758f6c1cdc7b36dcc5
MESSAGE=Starting nginx - high performance web server...
UNIT=newnginx.service
_SOURCE_REALTIME_TIMESTAMP=1433064458344553
Sun 2015-05-31 10:27:38.354983 BST [s=4cc44a9cf9344c948fd4716fe024439e;i=3199;b=be3381af5b1d4743a4ccc1e346eab405;m=1548bfd0ee;t=5175d51fb0127;x=bc50f03db39f8d09]
PRIORITY=6
_UID=0
_GID=0
_BOOT_ID=be3381af5b1d4743a4ccc1e346eab405
_MACHINE_ID=9619293167aa4f76b45b745e9f4e8935
_HOSTNAME=localhost.localdomain
_CAP_EFFECTIVE=1fffffffff
_SYSTEMD_CGROUP=/
SYSLOG_FACILITY=3
_SELINUX_CONTEXT=system_u:system_r:init_t:s0
_TRANSPORT=stdout
Обновление 2: сценарий Python для печати требуемых записей:
from systemd import journal
j = journal.Reader()
j.this_boot()
j.add_match(_SYSTEMD_UNIT="newnginx.service")
for entry in j:
print('{} {}'.format(entry['_SYSTEMD_UNIT'], entry['MESSAGE']))
Взгляните на этот пример из nginx:
[root@localhost tmp]# journalctl --unit nginx
-- Logs begin at Sun 2015-04-05 10:36:30 BST, end at Sun 2015-05-31 11:12:29 BST. --
May 31 10:20:41 localhost.localdomain systemd[1]: Starting nginx - high performance web server...
May 31 10:20:41 localhost.localdomain nginx[111169]: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
May 31 10:20:41 localhost.localdomain nginx[111169]: nginx: configuration file /etc/nginx/nginx.conf test is successful
May 31 10:20:41 localhost.localdomain systemd[1]: Failed to read PID from file /run/nginx.pid: Invalid argument
May 31 10:20:41 localhost.localdomain systemd[1]: Started nginx - high performance web server.
May 31 10:27:05 localhost.localdomain systemd[1]: Stopping nginx - high performance web server...
May 31 10:27:05 localhost.localdomain systemd[1]: Stopped nginx - high performance web server.
May 31 10:58:36 localhost.localdomain systemd[1]: Stopped nginx - high performance web server.
May 31 11:12:29 localhost.localdomain systemd[1]: Starting nginx - high performance web server...
May 31 11:12:29 localhost.localdomain nginx[112202]: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
May 31 11:12:29 localhost.localdomain nginx[112202]: nginx: configuration file /etc/nginx/nginx.conf test is successful
May 31 11:12:29 localhost.localdomain systemd[1]: Failed to read PID from file /run/nginx.pid: Invalid argument
May 31 11:12:29 localhost.localdomain systemd[1]: Started nginx - high performance web server.
Кто-то приходит и выполняет ps, чтобы найти и убить nginx:
[root@localhost tmp]# ps -ef | grep nginx
root 112205 1 0 11:12 ? 00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx 112207 112205 0 11:12 ? 00:00:00 nginx: worker process
root 112212 111775 0 11:12 pts/4 00:00:00 grep --color=auto nginx
[root@localhost tmp]# kill -9 112205
Теперь журнал содержит:
[root@localhost tmp]# journalctl --unit nginx
-- Logs begin at Sun 2015-04-05 10:36:30 BST, end at Sun 2015-05-31 11:12:57 BST. --
May 31 10:20:41 localhost.localdomain systemd[1]: Starting nginx - high performance web server...
May 31 10:20:41 localhost.localdomain nginx[111169]: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
May 31 10:20:41 localhost.localdomain nginx[111169]: nginx: configuration file /etc/nginx/nginx.conf test is successful
May 31 10:20:41 localhost.localdomain systemd[1]: Failed to read PID from file /run/nginx.pid: Invalid argument
May 31 10:20:41 localhost.localdomain systemd[1]: Started nginx - high performance web server.
May 31 10:27:05 localhost.localdomain systemd[1]: Stopping nginx - high performance web server...
May 31 10:27:05 localhost.localdomain systemd[1]: Stopped nginx - high performance web server.
May 31 10:58:36 localhost.localdomain systemd[1]: Stopped nginx - high performance web server.
May 31 11:12:29 localhost.localdomain systemd[1]: Starting nginx - high performance web server...
May 31 11:12:29 localhost.localdomain nginx[112202]: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
May 31 11:12:29 localhost.localdomain nginx[112202]: nginx: configuration file /etc/nginx/nginx.conf test is successful
May 31 11:12:29 localhost.localdomain systemd[1]: Failed to read PID from file /run/nginx.pid: Invalid argument
May 31 11:12:29 localhost.localdomain systemd[1]: Started nginx - high performance web server.
May 31 11:12:57 localhost.localdomain systemd[1]: nginx.service: main process exited, code=killed, status=9/KILL
May 31 11:12:57 localhost.localdomain kill[112215]: Usage:
May 31 11:12:57 localhost.localdomain kill[112215]: kill [options] <pid|name> [...]
May 31 11:12:57 localhost.localdomain kill[112215]: Options:
May 31 11:12:57 localhost.localdomain kill[112215]: -a, --all do not restrict the name-to-pid conversion to processes
May 31 11:12:57 localhost.localdomain kill[112215]: with the same uid as the present process
May 31 11:12:57 localhost.localdomain kill[112215]: -s, --signal <sig> send specified signal
May 31 11:12:57 localhost.localdomain kill[112215]: -q, --queue <sig> use sigqueue(2) rather than kill(2)
May 31 11:12:57 localhost.localdomain kill[112215]: -p, --pid print pids without signaling them
May 31 11:12:57 localhost.localdomain kill[112215]: -l, --list [=<signal>] list signal names, or convert one to a name
May 31 11:12:57 localhost.localdomain kill[112215]: -L, --table list signal names and numbers
May 31 11:12:57 localhost.localdomain kill[112215]: -h, --help display this help and exit
May 31 11:12:57 localhost.localdomain kill[112215]: -V, --version output version information and exit
May 31 11:12:57 localhost.localdomain kill[112215]: For more details see kill(1).
May 31 11:12:57 localhost.localdomain systemd[1]: nginx.service: control process exited, code=exited status=1
May 31 11:12:57 localhost.localdomain systemd[1]: Unit nginx.service entered failed state.
Обратите внимание, как столбец, в котором вы видите только php , содержит имя Здесь перечислены процессы, которые воздействуют на модуль nginx systemd, systemd, nginx, kill. Это поможет объяснить.
Имя модуля дается ему по имени файла. На Centos 7 я сделал:
(cfs)[root@localhost system]# pwd
/usr/lib/systemd/system
^?(cfs)[root@localhost system]# cp nginx.service newnginx.service
Остановить исходный nxginx:
(cfs)[root@localhost system]# service nginx stop
Redirecting to /bin/systemctl stop nginx.service
(cfs)[root@localhost system]# service h^Cinx stop
Посмотрите и запустите "newnginx":
(cfs)[root@localhost system]# service newnginx status
Redirecting to /bin/systemctl status newnginx.service
newnginx.service - nginx - high performance web server
Loaded: loaded (/usr/lib/systemd/system/newnginx.service; disabled)
Active: inactive (dead)
Docs: http://nginx.org/en/docs/
(cfs)[root@localhost system]# service newnginx start
Redirecting to /bin/systemctl start newnginx.service
Journalctl теперь перечисляет модуль newnginx
:
(cfs)[root@localhost system]# journalctl --unit newnginx
-- Logs begin at Sun 2015-04-05 10:36:30 BST, end at Sun 2015-05-31 10:27:38 BST. --
May 31 10:27:38 localhost.localdomain systemd[1]: Starting nginx - high performance web server...
May 31 10:27:38 localhost.localdomain nginx[111311]: nginx: the configuration file /etc/nginx/nginx.conf syntax is o
May 31 10:27:38 localhost.localdomain nginx[111311]: nginx: configuration file /etc/nginx/nginx.conf test is success
May 31 10:27:38 localhost.localdomain systemd[1]: Failed to read PID from file /run/nginx.pid: Invalid argument
May 31 10:27:38 localhost.localdomain systemd[1]: Started nginx - high performance web server.
Теперь есть два nginx systemd units:
# systemctl list-unit-files --all | grep nginx
newnginx.service disabled
nginx.service disabled
SyslogIdentifier = Устанавливает имя процесса («тег системного журнала») для префикса журнала строки, отправленные в систему журналирования или буфер журнала ядра с помощью. Если не set, по умолчанию используется имя выполняемого процесса. Этот вариант полезен, только если StandardOutput = или StandardError = установлено в journal, syslog или kmsg (или к тем же настройкам в сочетании с + console) и применяется только к сообщениям журнала, записанным в stdout или stderr.
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#SyslogIdentifier=
Это отменяет Поле SYSLOG_IDENTIFIER
в выводе journalctl
.
# cat /etc/systemd/system/prvzn.service | grep prvzn
ExecStart=/opt/infra/prvzn exec --config-dir ${CONFIG_DIR}
SyslogIdentifier=prvzn-foobar
Результат в строках journalctl, подобных этому:
# journalctl | grep prvzn | tail -n1
Apr 30 08:29:16 ro01 prvzn-foobar[31787]: prvzn (info)2018/04/30 08:29:16 evaluation successful.
Я запускаю смесь разных версий Ubuntu (14.04, 16.04, 17.10) и CentOS (7 ) ... моя собственная борьба заключается в том, что systemd быстро меняется, и многие параметры конфигурации не работают последовательно или в некоторых случаях даже недоступны между версиями. Проверьте страницы руководства для вашей конкретной версии systemd. ymmv