We're trying to run multiple DHCP processes on one system. They have their data in a instance-specific configuration directory and we'd like to limit (r/w for now) filesystem access to that directory for security reasons. ==> dhcpd@.service <== [Unit] Description=DHCP Instance %i After=syslog.target After=network.target [Service] ExecStart=/usr/sbin/dhcpd -cf /var/lib/dhcp/%i/etc/dhcpd.conf -lf /var/lib/dhcp/%i/db/dhcpd.leases -pf /var/lib/dhcp/%i/dhcpd.pid -f Type=simple Restart=on-failure CapabilityBoundingSet=CAP_NET_RAW CAP_NET_BIND_SERVICE NoNewPrivileges=true ReadOnlyDirectories=/ ReadWriteDirectories=/var/lib/dhcp/%i This does not work Apr 02 11:02:38 dns-w-neu systemd[1]: Started DHCP Instance b1peer2. Apr 02 11:02:38 dns-w-neu systemd[1]: Starting DHCP Instance b1peer2... Apr 02 11:02:38 dns-w-neu systemd[7760]: Failed at step NAMESPACE spawning /usr/sbin/dhcpd: No such file or directory Apr 02 11:02:38 dns-w-neu systemd[1]: dhcpd@b1peer2.service: main process exited, code=exited, status=226/NAMESPACE Apr 02 11:02:38 dns-w-neu systemd[1]: Unit dhcpd@b1peer2.service entered failed state. Apr 02 11:02:38 dns-w-neu systemd[1]: dhcpd@b1peer2.service failed. Apr 02 11:02:38 dns-w-neu systemd[1]: dhcpd@b1peer2.service holdoff time over, scheduling restart. The directory exists root@dns-w-neu:/var/lib/dhcp# ls -lad b1peer2 drwxr-xr-x 4 root root 4096 Apr 1 16:40 b1peer2 it works fine with either ReadWriteDirectories=/var/lib/dhcp and ReadWriteDirectories=/var/lib/dhcp/b1peer2 (which obviously won't work with other instances, but that's not the point here). So it seems that %i is not evaluated in ReadWriteDirectories (at least).
I have filed this in Debian first: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781730 It affects both v215 and v219
Hi, I stumbled on this bugzilla entry while searching for a solution for a related problem [1]. I guess we are looking at the same problem. Can you confirm that you get the same error message even if you are not using %i in ReadWriteDirectories paths? I guess you would also hit this bug if the instance placeholder (%i) is not used in that location. Example: Working service file (single instance) https://github.com/nusenu/tor-multi-instance-initscripts/blob/master/debian/tor.service Not working (multi instance but not using %i in ReadWriteDirectories path): https://github.com/nusenu/ansible-relayor/blob/c8914409b32b807aabcd625d4d9cc663b4d8603f/files/debian_tor%40.service [1] https://github.com/nusenu/ansible-relayor/issues/16
This will be fixed in v233 afaics. I don't know the relevant commits though. Lennart, maybe you can chime in here.
Yes, this has been implemented in: https://github.com/systemd/systemd/commit/7b07e99320586fa3baf3e6cbb374f06c6ddc47d8
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.