[systemd-devel] Failed at step RUNTIME_DIRECTORY spawning /usr/bin/true: File exists

[Lennart Poettering]

On Sat, 01.08.15 11:54, Reindl Harald (h.reindl at thelounge.net) wrote:

> 
> Am 27.07.2015 um 21:39 schrieb Lennart Poettering:
> >On Wed, 15.07.15 16:24, Reindl Harald (h.reindl at thelounge.net) wrote:
> >
> >>why does systemd *randomly* try to create "RuntimeDirectory"
> >>for "ExecStartPost" and so terminates a perfectly up and running service
> >>because the "file exists" error?
> >>
> >>Fedora 21 as well as Fedora 22
> >>https://bugzilla.redhat.com/show_bug.cgi?id=1226509#c3
> >>
> >>Jul 15 16:19:43 rawhide systemd: Stopping Test Unit...
> >>Jul 15 16:19:43 rawhide systemd: Stopped Test Unit.
> >>Jul 15 16:19:43 rawhide systemd: Starting Test Unit...
> >>Jul 15 16:19:43 rawhide systemd: Failed at step RUNTIME_DIRECTORY spawning
> >>/usr/bin/true: File exists
> >>Jul 15 16:19:43 rawhide systemd: test2.service: control process exited,
> >>code=exited status=233
> >>Jul 15 16:19:43 rawhide systemd: Failed to start Test Unit.
> >>Jul 15 16:19:43 rawhide systemd: Unit test2.service entered failed state.
> >>Jul 15 16:19:43 rawhide systemd: test2.service failed.
> >
> >Can you file an issue about this on github with a reproducer for v221
> >or v222? Thanks!
> 
> the reproducer is in https://bugzilla.redhat.com/show_bug.cgi?id=1226509#c3
> just a few lines of a systemd-unit
> 
> dunno if this affects v221 and v222 too - Fedora user
> but it is very likely since it exists from v216 to v219
> 
> why not just dig in the code and remove that completly useless "file exists"
> check instead be happy that the folder is already there?

So, you'll get this EEXIST error only if there's already something at
the place of the runtime dir that is either:

a) not a directory

or

b) a directory, but not owned by the user and group set for the
   service

or

c) a directory, but with a more loose access mode than specified in
   RuntimeDirectoryMode=.

systemd is completely fine with the directory pre-existing, as long as
it really is a directory, is owned by the right user and group and has
an access mode that is at least as strict as the configured one.

It would be good if you could verify that file data of the runtime dir
when this fails for you. Thanks.

Lennart

-- 
Lennart Poettering, Red Hat