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

Vasiliy G Tolstov v.tolstov at selfip.ru
Thu May 26 05:48:54 PDT 2011


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 ?

-- 
Vasiliy G Tolstov <v.tolstov at selfip.ru>
Selfip.Ru



More information about the systemd-devel mailing list