Change systemd unit tag send to journalctl/syslog

Question

Is it possible to change what tag systemd managed service uses for logging? For example, my custom service report-daemon.service defined as

# ...
[Service]
ExecStart=/usr/bin/php # ...
# ...

shows up as php instead of report-daemon (it seems to infer the tag from 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
# ...

Man page does not list any option for setting this in unit file. Is it possible to change the tag somewhere?

gm3dmo · Accepted Answer · 2015-06-01 07:44:48Z

Update 1: The verbose option will list in long format and so includes the 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

Update 2: Python script to print wanted entries:

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']))

Have a look at this example from 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.

Somebody comes along and does a ps to find and kill 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

The journal now contains:

[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.

Observe how the column where you are seeing only php contains the name of the process that is acting upon the nginx systemd unit, systemd, nginx, kill are all listed there. Does that help to explain.

The unit name is given to it by the filename. On a Centos 7 I did:

(cfs)[root@localhost system]# pwd
/usr/lib/systemd/system

^?(cfs)[root@localhost system]# cp nginx.service newnginx.service

Stop the original nxginx:

(cfs)[root@localhost system]# service nginx stop
Redirecting to /bin/systemctl stop  nginx.service
(cfs)[root@localhost system]# service h^Cinx stop

Look at and start "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 now lists the newnginx unit:

(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.

There are now two nginx systemd units:

# systemctl list-unit-files --all | grep nginx
newnginx.service                            disabled
nginx.service                               disabled

Ok, thanks, that somewhat explains the current behaviour. The original question still stands though; I would rather see it tagged with the service name regardless of what the process is (eg always nginx instead of kill etc). Is that absolutely impossible? — Mikulas Dite, May 31, 2015 at 17:23
Hi, I've added 2 updates to the answer: You can get the unit name with "verbose" output and on my Centos at least the system python has a systemd module so you can create your own custom outputs using that, I've added a python snippet. — gm3dmo, Jun 1, 2015 at 7:47
Somebody also answered this in stackoverflow: stackoverflow.com/questions/24403387/… — gm3dmo, Jun 1, 2015 at 7:49

mattpr · Accepted Answer · 2023-12-04 15:22:18Z

SyslogIdentifier= Sets the process name ("syslog tag") to prefix log lines sent to the logging system or the kernel log buffer with. If not set, defaults to the process name of the executed process. This option is only useful when StandardOutput= or StandardError= are set to journal, syslog or kmsg (or to the same settings in combination with +console) and only applies to log messages written to stdout or stderr.

https://www.freedesktop.org/software/systemd/man/systemd.exec.html#SyslogIdentifier=

This overrides the SYSLOG_IDENTIFIER field in journalctl output.

# grep prvzn /etc/systemd/system/prvzn.service
ExecStart=/opt/infra/prvzn exec --config-dir ${CONFIG_DIR} 
SyslogIdentifier=prvzn-foobar

Results in journalctl lines like this:

# journalctl | grep prvzn | tail -n1
Apr 30 08:29:16 ro01 prvzn-foobar[31787]: prvzn (info)2018/04/30 08:29:16 evaluation successful.

I am running a mix of different versions of Ubuntu (14.04, 16.04, 17.10) and CentOS (7) ...my own struggle is that systemd has been changing rapidly and many config options don't work consistently or in some cases aren't even available between versions. Check the man pages for your specific version of systemd. ymmv

perfect answer, exactly what I was looking for, but couldn't find in the systemd docs. So much cleaner than adding systemd or setproctitle into my own app! top nice very thanks :) — Karl P, Jun 21, 2019 at 23:49
This should be the accepted answer to the original question. — utdrmac, Oct 14, 2019 at 16:34

Stack Exchange Network

Change systemd unit tag send to journalctl/syslog

2 Answers 2

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged
logging
systemd
.

Linked

Hot Network Questions

Change systemd unit tag send to journalctl/syslog

2 Answers 2

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged loggingsystemd.

Linked

Related

Hot Network Questions

Not the answer you're looking for? Browse other questions tagged
logging
systemd
.