Arch Linux

grant.traynor

Member

Registered: 2020-12-29

Posts: 6

systemd tmpfiles.d not creating entry in /run

Hi,

I'm trying to get my head around using systemd tmpfiles to setup some entries in /run. Following these instructions:
1. https://wiki.archlinux.org/index.php/Sy … rary_files
2. https://man.archlinux.org/man/systemd-tmpfiles.8

I'm trying to get some tmpfiles created at boot / under systemd's management:

I have:

# cat /usr/lib/tmpfiles.d/opendkim.conf 
d /run/opendkim 0755 opendkim postfix -

# systemctl restart systemd-tmpfiles-clean.service
# ls /run/ | grep open

# systemd-tmpfiles --create
# ls /run/ | grep open
opendkim

If I reboot the node:

# ls /run/ | grep open

Am I understanding this right? I would have expected this directory to be created both at boot, and when I restart the systemd-tmpfiles-clean.service. From the manpage:

To re-apply settings after configuration has been modified, simply restart systemd-tmpfiles-clean.service, which will apply any settings which can be safely executed at runtime. To debug systemd-tmpfiles, it may be useful to invoke it directly from the command line with increased log level (see $SYSTEMD_LOG_LEVEL below).

loqs

Member

Registered: 2014-03-06

Posts: 19,015

Re: systemd tmpfiles.d not creating entry in /run

systemd-tmpfiles-clean.service executes systemd-tmpfiles --clean,  which will only remove expired content.
File and directory creation is performed by systemd-tmpfiles-setup.service which executes systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev.

grant.traynor

Member

Registered: 2020-12-29

Posts: 6

Re: systemd tmpfiles.d not creating entry in /run

Hi @loqs,

Thanks for your response, and yes, that's right.

So I'm trying to work out:
1. Why doesn't the documentation ask you to bounce that service, instead of the cleanup service?
2. Should you bounce that service? When does it run?
3. Is the Arch implementation of systemd consistent with upstream?
4. Or have I just misunderstood how this works. (entirely possible)

As already noted, those files aren't created on reboot ... this is when I expected the setup service to run.

So ... trying to bounce the systemd-tmpfiles-setup.service ...

# ls /run/ | grep open
# systemctl restart systemd-tmpfiles-setup
Failed to restart systemd-tmpfiles-setup.service: Operation refused, unit systemd-tmpfiles-setup.service may be requested by dependency only (it is configured to refuse manual start/stop).
See system logs and 'systemctl status systemd-tmpfiles-setup.service' for details.

# systemctl start systemd-tmpfiles-setup
# ls /run/ | grep open

So you cant' "restart" it. And "start" it doesn't create the tmpfiles.

# systemctl stop systemd-tmpfiles-setup
Failed to stop systemd-tmpfiles-setup.service: Operation refused, unit systemd-tmpfiles-setup.service may be requested by dependency only (it is configured to refuse manual start/stop).
See system logs and 'systemctl status systemd-tmpfiles-setup.service' for details.
# ls /run/ | grep open

And finally back to....

# systemd-tmpfiles --create
# ls /run/ | grep open
opendkim

So the systemd documentation and the Arch implementation seem to me to be inconsistant? Or am I missing the point?

If I change the systemd-tmpfiles-clean.service and add --create to the service definition file, like this:

#  SPDX-License-Identifier: LGPL-2.1-or-later
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Cleanup of Temporary Directories
Documentation=man:tmpfiles.d(5) man:systemd-tmpfiles(8)
DefaultDependencies=no
Conflicts=shutdown.target
After=local-fs.target time-set.target
Before=shutdown.target

[Service]
Type=oneshot
ExecStart=systemd-tmpfiles --create --clean
SuccessExitStatus=DATAERR
IOSchedulingClass=idle

And rebounce the service, it seems to work...

# systemctl daemon-reload
# systemctl restart systemd-tmpfiles-clean
# ls /run/ | grep open
opendkim

This looks to me to be more consistent with the expected behaviour, but I'm not really an expert on this stuff.

But, even with this change, I still need to manually bounce systemd-tmpfiles-clean.service on a boot to create the tmpfiles.

Starting to think maybe I just do back to the old init.rc script ...

Appreciate any help.

loqs

Member

Registered: 2014-03-06

Posts: 19,015

Re: systemd tmpfiles.d not creating entry in /run

Hi @loqs,

Thanks for your response, and yes, that's right.

So I'm trying to work out:
1. Why doesn't the documentation ask you to bounce that service, instead of the cleanup service?

You would need to check this with upstream but I would suspect because it is not considered safe to restart it.

2. Should you bounce that service? When does it run?

Arch calls systemd-tempfiles --create from /usr/share/libalpm/scripts/systemd-hook when it encounters a new or changed tempfiles config instead of restarting the service.
By default the service runs at boot

3. Is the Arch implementation of systemd consistent with upstream?

Ask upstream?

As already noted, those files aren't created on reboot ... this is when I expected the setup service to run.

What is the output on boot of

systemctl status systemd-tmpfiles-setup.service