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

Kay Sievers kay.sievers at vrfy.org
Thu May 26 05:45:44 PDT 2011


On Thu, May 26, 2011 at 14:38, Lennart Poettering
<lennart at poettering.net> wrote:
> On Thu, 26.05.11 12:53, Vasiliy G Tolstov (v.tolstov at selfip.ru) wrote:
>
>> On Thu, 2011-05-26 at 16:52 +0800, microcai wrote:
>> > 于 2011年05月26日 16:33, Vasiliy G Tolstov 写道:
>> > > Hello. If i want to write daemon, that can be running by regular init
>> > > system (openrc, upstart and others) and systemd, how can i check inside
>> > > my daemon, that it runs from systemd?
>> > > In compile phase, i can build with systemd support and install service
>> > > file, but if i do not want to write and build separate binaries for two
>> > > init daemons, how can i solve this?
>> > >
>> >
>> > check sd-booted()
>> >
>>
>> correct is sd_booted , thank you!
>
> 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.

See udev. We either get the file descriptors from systemd, or we call
socket() on our own. There is no other check than the passed-in fds to
decide what we do:
  http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=udev/udevd.c;h=e7384e19a2431b1007680bc10e4290647dfcc9a1;hb=HEAD#l1356

Kay


More information about the systemd-devel mailing list