> From what I've seen in Lennart's posts, adding systemd support doesn't
> seem to be too complicated.

No. No changes at all are necessary to be compatible with systemd.
This is a very impressive feature of systemd; at the same time, this is
what complicates systemd, and creates a dependency on cgroups.

If you have a daemon that forks and creates a pidfile, just say

Type=forking
PIDFile=/var/run/daemon.pid

If you have a daemon that forks and doesn't create a pidfile, systemd
will try to guess the main pid. I kid you not.

If you have a daemon that doesn't fork and is able to satisfy its
dependencies straight away, just say

Type=simple

If you have a daemon that doesn't fork and needs some time before it can
satisfy its dependencies (say, because it needs to create some sockets
first) but advertises itself on dbus, just say

Type=dbus

Finally, if you have a deamon that doesn't fork, cannot satisfy its
dependencies straight away, and doesn't advertise itself on dbus, you
need to add three lines of code to your daemon (to notify systemd that
it's finished initialising), link with an MIT/X11-licensed file provided
with systemd, and say

type=notify

Is that cool? Is that bloat? I say yes to both.

-- Juliusz


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87aac6p3px.fsf_-_@trurl.pps.jussieu.fr">http://lists.debian.org/87aac6p3px.fsf_-_@trurl.pps.jussieu.fr

On Fri, Jul 22, 2011 at 3:31 PM, Juliusz Chroboczek <jch@pps.jussieu.fr> wrote:
>> From what I've seen in Lennart's posts, adding systemd support doesn't
>> seem to be too complicated.
>
> No. *No changes at all are necessary to be compatible with systemd.
> This is a very impressive feature of systemd; at the same time, this is
> what complicates systemd, and creates a dependency on cgroups.

I was referring to socket activation.

> Is that cool? *Is that bloat? *I say yes to both.

I'd rather avoid the word "bloat" in this discussion, as it's very
often misused.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CANVYNa_XWfHVT90P0Myk5c-6P4oN0Oo_vUzJUL30n4hKeEK_Og@mail.gmail.com">http://lists.debian.org/CANVYNa_XWfHVT90P0Myk5c-6P4oN0Oo_vUzJUL30n4hKeEK_Og@mail.gmail.com

Juliusz Chroboczek writes ("Making daemons compatible with systemd [was: Minimal init]"):
> > From what I've seen in Lennart's posts, adding systemd support doesn't
> > seem to be too complicated.
>
> No. No changes at all are necessary to be compatible with systemd.
> This is a very impressive feature of systemd; at the same time, this is
> what complicates systemd, and creates a dependency on cgroups.

I don't think this is a good tradeoff.

It is much better to modify the few upstream daemons which would need
patching, than to add all of this extra machinery to support what
seems to me to be a design whose entire purpose is to workaround a
to-my-mind-broken interface paradigm (daemon(3)) invented decades ago.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20024.16123.959575.290975@chiark.greenend.org.uk"> http://lists.debian.org/20024.16123.959575.290975@chiark.greenend.org.uk

]] Ian Jackson

| It is much better to modify the few upstream daemons which would need
| patching, than to add all of this extra machinery to support what
| seems to me to be a design whose entire purpose is to workaround a
| to-my-mind-broken interface paradigm (daemon(3)) invented decades ago.

I'm looking forward to your patches for the proprietary HP and Dell
daemons that are used for monitoring the health of various hardware
components.

(Sure, they might not be packaged for Debian, but adopting an init
system that doesn't deal with double-forking would be much, much worse
than adopting one which is Linux-specific for our Linux ports.)

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87oc07lhbx.fsf@qurzaw.varnish-software.com">http://lists.debian.org/87oc07lhbx.fsf@qurzaw.varnish-software.com

Tollef Fog Heen writes ("Re: Making daemons compatible with systemd"):
> I'm looking forward to your patches for the proprietary HP and Dell
> daemons that are used for monitoring the health of various hardware
> components.

Those daemons can continue to be started and managed the way they are
already, with all the unreliability that daemon(3)+pidfiles implies.

If the vendors of those programs care about this they can provide a
new interface, and if the customers care they can try to make the
vendors care.

> (Sure, they might not be packaged for Debian, but adopting an init
> system that doesn't deal with double-forking would be much, much worse
> than adopting one which is Linux-specific for our Linux ports.)

I'm not suggesting that we should do anything that makes the existing
situation worse. We should not adopt an init system that, with
double-forking daemons and init scripts, fails to work as well as that
approach currently does with sysvinit.

But I don't think it is a good idea to adopt a complicated workaround
(which is essentially what the cgroups approach is), to get proper
daemon supervision, when we can simply fix the root cause.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20025.22114.712473.868071@chiark.greenend.org.uk"> http://lists.debian.org/20025.22114.712473.868071@chiark.greenend.org.uk

Ian Jackson <ijackson <at> chiark.greenend.org.uk> writes:
> But I don't think it is a good idea to adopt a complicated workaround
> (which is essentially what the cgroups approach is), to get proper
> daemon supervision, when we can simply fix the root cause.

This is a bit like saying that there's no need for the kernel to free allocated
resources when a process exits, when we can simply fix all programs to free
resources before exiting.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: loom.20110803T172938-277@post.gmane.org">http://lists.debian.org/loom.20110803T172938-277@post.gmane.org