[systemd-devel] combine old-style sysvinit daemon and new-style systemd

[Lennart Poettering]

On Thu, 26.05.11 16:48, Vasiliy G Tolstov (v.tolstov at selfip.ru) wrote:

> 
> On Thu, 2011-05-26 at 14:38 +0200, Lennart Poettering wrote:
> 
> > 
> > No, please don't. These interfaces have been designed in a way that
> > other init systems could use them too. If you however invoke sd_booted()
> > explicitly you ensure that your code won't work on other init systems
> > exposing the same interfaces.
> > 
> > sd_listen_fds() will return 0 if not used in a socket-activated
> > way. Hence, if you see this call return 0 then act as you did before and
> > allocate the sockets yourself.
> > 
> > sd_notify() becomes a NOP if no systemd-compatible init systemis
> > running, so just call it unconditionally.
> > 
> > So, really, there is no need, no need at all, to invoke sd_booted() to
> > guard these calls.
> > 
> > Lennart
> > 
> 
> Ok, this means, that for socket-activated daemon, i'm simple run
> sd_listen_fds and check ret val...
> if i ran in standalone mode, i can do sd_notify for example with MAINPID
> and check ret? Doc says:
>        On failure, these calls return a negative errno-style error code.
> If $NOTIFY_SOCKET was not set and hence no status data could be sent, 0
> is returned. If the status was sent these
>        functions return with a positive return value. In order to
> support both, init systems that implement this scheme and those which
> don't, it is generally recommended to ignore the
>        return value of this call.
> 
> 
> How can i check systemd in case not socket-activated mode ?

Hmm?

sd_notify() does nothing on systems which don't support the systemd
notification interfaces. Hence, just call it where appropriate, and rest
assured that it has no ill effect (or any effect at all) if your daemon
is not running from systemd. sd_notify() already does all necessary
checking internally if you so will.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.