[systemd-devel] Failed at step RUNTIME_DIRECTORY spawning /usr/bin/true: File exists
Ivan Shapovalov
intelfx100 at gmail.com
Mon Aug 10 06:05:13 PDT 2015
On 2015-08-10 at 11:16 +0200, Reindl Harald wrote:
>
> Am 10.08.2015 um 07:57 schrieb Ivan Shapovalov:
> > On 2015-08-06 at 15:01 +0200, Michael Biebl wrote:
> > > 2015-08-06 14:43 GMT+02:00 Reindl Harald <h.reindl at thelounge.net>
> > > :
> > > > well, but "Type=simple" is default and recommended everywhere
> > > > because there
> > > > is no main-pid to guess and the with "Restart=always" monitored
> > > > is
> > > > in fact
> > > > "ExecStart"
> > >
> > > Actually, Type=simple has its own share of problems:
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778913
> >
> > That's a direct consequence of Type=simple semantics. From
> > systemd's
> > standpoint, a daemon which crashes 10ms after start-up due to bad
> > config is indistinguishable from a daemon which crashes 10hrs after
> > starting due to an internal error.
> >
> > To make things more robust, the daemon should either *properly*
> > implement Type=forking (i. e. fork only after initial start-up)
> > or it should implement Type=notify
>
> sorry but in context of the topic that's wrong
Moreover,
>
> * "RuntimeDirectory" is a service configuration
> * the daemon is started as unprivileged user
> * "RuntimeDirectory" should be created long before
> ExecStart / ExecStartPost
This is wrong. The runtime directory "will be created <...> when
the unit is started, and removed when the unit is stopped".
As can be seen from the code, the runtime directory creation is
attempted on execution of each configured process, be it ExecStart= or
ExecStartPost= (or whatever else).
--
Ivan Shapovalov / intelfx /
> and hence i wonder how
> there can exist a race condition at all, there
> is no valid reason trying to create it twice
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150810/42a6c7b6/attachment.sig>
More information about the systemd-devel
mailing list