Debian Bug report logs - #752075
daemontools-run: Add systemd support

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Joern Heissler <debbugs@joern.heissler.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: daemontools-run: Add systemd support

Date: Thu, 19 Jun 2014 12:54:06 +0200

Package: daemontools-run
Version: 1:0.76-3
Severity: grave
Justification: renders package unusable

Hi,
Debian decided to use systemd.

I'm using a local dnscache (djbdns) for recursive dns lookups, but this
service isn't started automatically. I assume that it's because
daemontools-run only supports sysvinit's inittab.

Please add systemd support,
Cheers!


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages daemontools-run depends on:
ii  daemontools  1:0.76-3

daemontools-run recommends no packages.

daemontools-run suggests no packages.

-- no debconf information

Message #10 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Gerrit Pape <pape@dbnbgs.smarden.org>

To: Joern Heissler <debbugs@joern.heissler.de>, 752075@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#752075: daemontools-run: Add systemd support

Date: Fri, 4 Jul 2014 09:08:21 +0000

Hi,

I looked into latest policy, but did not find anything about systemd
support.  I'm surprised that this is now a release critical bug, and the
package marked for removal.  What's the justification?

This package hooks into /etc/inittab, does systemd not automatically
manage services from inittab?  Isn't it systemd having release critical
bug then?

Regards, Gerrit


On Thu, Jun 19, 2014 at 12:54:06PM +0200, Joern Heissler wrote:
> Package: daemontools-run
> Version: 1:0.76-3
> Severity: grave
> Justification: renders package unusable
> 
> Hi,
> Debian decided to use systemd.
> 
> I'm using a local dnscache (djbdns) for recursive dns lookups, but this
> service isn't started automatically. I assume that it's because
> daemontools-run only supports sysvinit's inittab.
> 
> Please add systemd support,
> Cheers!
> 
> 
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers unstable
>   APT policy: (600, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages daemontools-run depends on:
> ii  daemontools  1:0.76-3
> 
> daemontools-run recommends no packages.
> 
> daemontools-run suggests no packages.
> 
> -- no debconf information

Message #15 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Ansgar Burchardt <ansgar@debian.org>

To: 752075@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#752075: daemontools-run: Add systemd support

Date: Fri, 04 Jul 2014 12:01:13 +0200

Hi,

On 07/04/2014 11:08, Gerrit Pape wrote:
> I looked into latest policy, but did not find anything about systemd
> support.  I'm surprised that this is now a release critical bug, and the
> package marked for removal.  What's the justification?

Ask the submitter?

> This package hooks into /etc/inittab, does systemd not automatically
> manage services from inittab?  Isn't it systemd having release critical
> bug then?

Could we please not have another systemd thread on -devel@? The last one
is not even cold yet... Thanks!

Unrelated to that, I would think that any package that modifies
/etc/inittab is buggy: maintainer scripts should not modify
configuration files belonging to other packages (Policy 10.7.4).

Even worse, daemontools-run adds a new entry uncoditionally on upgrade
even when the existing one was removed/commented out by the local admin.
That's a RC bug (Policy 10.7.3: "local changes must be preserved during
a package upgrade")...

Ansgar

Message #20 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Ondřej Surý <ondrej@sury.org>

To: Gerrit Pape <pape@dbnbgs.smarden.org>, 752075@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#752075: daemontools-run: Add systemd support

Date: Fri, 04 Jul 2014 12:06:41 +0200

Gerrit,

it's up to you to lower the severity of the bug to "important" (I guess
since it will break with default init system).

You should have done that instead of ccing debian-devel in the
current situation.

Please do not abuse debian-devel to questions that could be politely
and calmly discussed outside the list.

Thanks,
O.

On Fri, Jul 4, 2014, at 11:08, Gerrit Pape wrote:
> Hi,
> 
> I looked into latest policy, but did not find anything about systemd
> support.  I'm surprised that this is now a release critical bug, and the
> package marked for removal.  What's the justification?
> 
> This package hooks into /etc/inittab, does systemd not automatically
> manage services from inittab?  Isn't it systemd having release critical
> bug then?
> 
> Regards, Gerrit
> 
> 
> On Thu, Jun 19, 2014 at 12:54:06PM +0200, Joern Heissler wrote:
> > Package: daemontools-run
> > Version: 1:0.76-3
> > Severity: grave
> > Justification: renders package unusable
> > 
> > Hi,
> > Debian decided to use systemd.
> > 
> > I'm using a local dnscache (djbdns) for recursive dns lookups, but this
> > service isn't started automatically. I assume that it's because
> > daemontools-run only supports sysvinit's inittab.
> > 
> > Please add systemd support,
> > Cheers!
> > 
> > 
> > -- System Information:
> > Debian Release: jessie/sid
> >   APT prefers unstable
> >   APT policy: (600, 'unstable')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> > 
> > Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
> > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > 
> > Versions of packages daemontools-run depends on:
> > ii  daemontools  1:0.76-3
> > 
> > daemontools-run recommends no packages.
> > 
> > daemontools-run suggests no packages.
> > 
> > -- no debconf information
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
> Archive:
> https://lists.debian.org/20140704090821.13265.qmail@79b6c771442573.315fe32.mid.smarden.org
> 


-- 
Ondřej Surý <ondrej@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

Message #25 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: 752075@bugs.debian.org

Cc: debian-devel@lists.debian.org

Subject: Re: Bug#752075: daemontools-run: Add systemd support

Date: Fri, 04 Jul 2014 03:37:20 -0700

Gerrit Pape <pape@dbnbgs.smarden.org> writes:

> I looked into latest policy, but did not find anything about systemd
> support.  I'm surprised that this is now a release critical bug, and the
> package marked for removal.  What's the justification?

I'm very dubious about this being release-critical.

> This package hooks into /etc/inittab, does systemd not automatically
> manage services from inittab?

Correct, systemd doesn't use inittab.

> Isn't it systemd having release critical bug then?

I don't think it's likely that systemd will support inittab.  The
semantics of inittab are quite a bit inferior to what's available with
very little additional work using the native configuration format, and the
regular inittab jobs are provided by regularly-configured services.  Yes,
that is a disruptive change for people who were using inittab to run other
things.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #30 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Joern Heissler <debbugs@joern.heissler.de>

To: 752075@bugs.debian.org, Gerrit Pape <pape@dbnbgs.smarden.org>

Subject: Re: Bug#752075: daemontools-run: Add systemd support

Date: Fri, 4 Jul 2014 12:42:43 +0200

Hi,

On Fri, Jul 04, 2014 at 09:08:21AM +0000, Gerrit Pape wrote:
> This package hooks into /etc/inittab, does systemd not automatically
> manage services from inittab?  Isn't it systemd having release critical

For clarity: daemontools-run does *not* include a file in /etc/init.d/
which systemd might use, instead it adds this line to /etc/inittab:
SV:123456:respawn:/usr/bin/svscanboot

systemd's source doesn't even include the word "inittab" and I wouldn't
expect it to. I don't think that it's systemd's fault.

> I looked into latest policy, but did not find anything about systemd
> support.  I'm surprised that this is now a release critical bug, and the
> package marked for removal.  What's the justification?

With the current stable (wheezy) this package works for most users.

I assume that the next stable release, Jessie, will use systemd by
default: https://lists.debian.org/debian-ctte/2014/02/msg00405.html

So upon release, when this bug is not fixed yet, the package becomes
useless for most users.
"makes the package in question unusable" hence I choose "grave" as severity.

I was actually tempted to mark it "critical". "makes … the whole system … break".
Because that's what happens for me. Upon reboot, there's no working DNS
resolution (nameserver 127.0.0.1, using djbdns).
But I assume that this setup is not very common.

Now I'm wondering about a few things:
* Can I only choose a release-critical severity for bugs affecting the
  current stable but not the next stable?
* Is there documentation clearly describing this?
* If I want to use djb's dnscache, is it the correct way to
  install daemontools and daemontools-run, or is there any better way?

My knowledge of Debian's policies is limited, so if you believe that my
reasoning above is flawed, please point me to the relevant sections of
the docs.

Cheers
Joern

Message #35 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Gerrit Pape <pape@dbnbgs.smarden.org>

To: Joern Heissler <debbugs@joern.heissler.de>, 752075@bugs.debian.org

Subject: Re: Bug#752075: daemontools-run: Add systemd support

Date: Fri, 4 Jul 2014 11:09:34 +0000

Hi Joern, you did nothing wrong.  Severity and justification looks quite
right to me.

On Fri, Jul 04, 2014 at 12:42:43PM +0200, Joern Heissler wrote:
> On Fri, Jul 04, 2014 at 09:08:21AM +0000, Gerrit Pape wrote:
> > I looked into latest policy, but did not find anything about systemd
> > support.  I'm surprised that this is now a release critical bug, and the
> > package marked for removal.  What's the justification?
> 
> With the current stable (wheezy) this package works for most users.
> 
> I assume that the next stable release, Jessie, will use systemd by
> default: https://lists.debian.org/debian-ctte/2014/02/msg00405.html
> 
> So upon release, when this bug is not fixed yet, the package becomes
> useless for most users.
> "makes the package in question unusable" hence I choose "grave" as severity.

Yep, fully understandable from you POV, thanks for filing the bug.

> * Can I only choose a release-critical severity for bugs affecting the
>   current stable but not the next stable?

Bug reporters are free to choose any severity they think applies.  It's
the maintainer setting it straight if she doesn't agree.

I'm just asking debian-devel how to resolve this.  I heard systemd is
backward-compatible to sysvinit, but looks like this doesn't apply to
the inittab interface.

Regards, Gerrit

Message #40 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Gerrit Pape <pape@dbnbgs.smarden.org>

To: debian-devel@lists.debian.org, 752075@bugs.debian.org

Subject: RFH: Re: Bug#752075: daemontools-run: Add systemd support

Date: Fri, 4 Jul 2014 11:50:52 +0000

On Fri, Jul 04, 2014 at 03:37:20AM -0700, Russ Allbery wrote:
> Gerrit Pape <pape@dbnbgs.smarden.org> writes:
> > I looked into latest policy, but did not find anything about systemd
> > support.  I'm surprised that this is now a release critical bug, and the
> > package marked for removal.  What's the justification?
> 
> I'm very dubious about this being release-critical.

I think it is.  The package will not work as expected without the
inittab interface.

> > This package hooks into /etc/inittab, does systemd not automatically
> > manage services from inittab?
> 
> Correct, systemd doesn't use inittab.
> 
> > Isn't it systemd having release critical bug then?
> 
> I don't think it's likely that systemd will support inittab.  The
> semantics of inittab are quite a bit inferior to what's available with
> very little additional work using the native configuration format, and the
> regular inittab jobs are provided by regularly-configured services.  Yes,
> that is a disruptive change for people who were using inittab to run other
> things.

Thanks Russ.  This also applies to the runit package actually.

Having my own init system since more than 10 years, I'm not that much in
systemd.  I looked at policy, but didn't find any instructions.

I hereby ask for help to add systemd support to these packages.

Important thing to know is: init scripts don't work out for this.  The
service management concept of daemontools and runit is, amongst other
things, a process tree with guaranteed process state, including
envrionment.  init scripts don't provide that.

Regards, Gerrit.

Message #45 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Matthias Urlichs <matthias@urlichs.de>

To: debian-devel@lists.debian.org, 752075@bugs.debian.org

Subject: Re: RFH: Re: Bug#752075: daemontools-run: Add systemd support

Date: Fri, 4 Jul 2014 14:17:46 +0200

Hi,

Gerrit Pape:
> > I'm very dubious about this being release-critical.
> 
> I think it is.  The package will not work as expected without the
> inittab interface.
> 
It's rather trivial to write an init script, and/or a systemd unit file,
which starts daemontools. Hooking into inittab isn't going to work with any
other init system, not just not with systemd.

> Having my own init system since more than 10 years, I'm not that much in
> systemd.  I looked at policy, but didn't find any instructions.
> 
You can start with the systemd.unit manpage. Searching the web for
"systemd howto write unit file" also yields some useful resources.

> Important thing to know is: init scripts don't work out for this.  The
> service management concept of daemontools and runit is, amongst other
> things, a process tree with guaranteed process state, including
> envrionment.  init scripts don't provide that.
> 
Well … systemd does.

-- 
-- Matthias Urlichs

Message #50 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: debian-devel@lists.debian.org

Cc: 752075@bugs.debian.org

Subject: Re: RFH: Re: Bug#752075: daemontools-run: Add systemd support

Date: Fri, 04 Jul 2014 05:37:38 -0700

Gerrit Pape <pape@dbnbgs.smarden.org> writes:

> Important thing to know is: init scripts don't work out for this.  The
> service management concept of daemontools and runit is, amongst other
> things, a process tree with guaranteed process state, including
> envrionment.  init scripts don't provide that.

There's no reason to switch away from inittab for sysvinit.  For systemd,
a unit file can easily do everything that you would get from inittab.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #55 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Ansgar Burchardt <ansgar@debian.org>

To: 752075@bugs.debian.org

Subject: Re: RFH: Re: Bug#752075: daemontools-run: Add systemd support

Date: Fri, 04 Jul 2014 14:41:07 +0200

Hi,

On 07/04/2014 13:50, Gerrit Pape wrote:
> Important thing to know is: init scripts don't work out for this.  The
> service management concept of daemontools and runit is, amongst other
> things, a process tree with guaranteed process state, including
> envrionment.  init scripts don't provide that.

Something similar to an entry in inittab should be easy to achieve with
systemd: it starts all processes in a controlled environment, can
monitor them and restart services on exit/failure.

Of course systemd will see all processes managed by daemontools-run as
belonging to the daemontools-run service, but that should not be too bad.

Something like

+---
| [Unit]
| Description=daemontools service supervision
| Documentation=man:svscanboot(8)
|
| [Service]
| ExecStart=/usr/bin/svscanboot
| Restart=always
|
| [Install]
| WantedBy=multi-user.target
+---

might already be enough as a .service file for daemontools.

Ansgar

Message #60 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Ansgar Burchardt <ansgar@debian.org>

To: 752075@bugs.debian.org

Subject: Re: RFH: Re: Bug#752075: daemontools-run: Add systemd support

Date: Fri, 04 Jul 2014 15:04:46 +0200

On 07/04/2014 14:41, Ansgar Burchardt wrote:
> Something like
> 
> +---
> | [Unit]
> | Description=daemontools service supervision
> | Documentation=man:svscanboot(8)
> |
> | [Service]
> | ExecStart=/usr/bin/svscanboot
> | Restart=always
> |
> | [Install]
> | WantedBy=multi-user.target
> +---
> 
> might already be enough as a .service file for daemontools.

This works, but there might be optional changes that provide a bit more
integration into systemd:

+---
| [Unit]
| Description=daemontools service supervision
| Documentation=man:svscan(8)
|
| [Service]
| ExecStart=/usr/bin/svscan /etc/service
| StandardOutput=journal
| StandardError=inherit
| Restart=always
|
| [Install]
| WantedBy=multi-user.target
+---

With this .service file, there is no longer a

  svscan ... | readproctitle ...

pipe, but the error messages are instead logged to the journal. They are
easily accessible when checking the state of daemontools via systemctl:

-----------------------------------------------------------------------
# systemctl status daemontools
daemontools.service - daemontools service supervision
   Loaded: loaded (/etc/systemd/system/daemontools.service; disabled)
   Active: active (running) since Fri 2014-07-04 14:53:52 CEST; 59s ago
     Docs: man:svscan(8)
 Main PID: 16870 (svscan)
   CGroup: /system.slice/daemontools.service
           ├─16870 /usr/bin/svscan /etc/service
           ├─16871 supervise sleep
           ├─16942 /bin/bash ./run
           └─16943 sleep 60

Jul 04 14:54:36 snout svscan[16870]: supervise: fatal: unable to start
sleep/run: access denied
Jul 04 14:54:37 snout svscan[16870]: supervise: fatal: unable to start
sleep/run: access denied
Jul 04 14:54:38 snout svscan[16870]: supervise: fatal: unable to start
sleep/run: access denied
Jul 04 14:54:39 snout svscan[16870]: supervise: fatal: unable to start
sleep/run: access denied
Jul 04 14:54:40 snout svscan[16870]: supervise: fatal: unable to start
sleep/run: access denied
Jul 04 14:54:41 snout svscan[16870]: supervise: fatal: unable to start
sleep/run: access denied
Jul 04 14:54:42 snout svscan[16870]: supervise: fatal: unable to start
sleep/run: access denied
Jul 04 14:54:43 snout svscan[16870]: supervise: fatal: unable to start
sleep/run: access denied
Jul 04 14:54:44 snout svscan[16870]: supervise: fatal: unable to start
sleep/run: access denied
Jul 04 14:54:45 snout svscan[16870]: supervise: fatal: unable to start
sleep/run: access denied
-----------------------------------------------------------------------

Killing svscan restarts the service as expected:

-----------------------------------------------------------------------
# kill 16870
# systemctl status daemontools
daemontools.service - daemontools service supervision
   Loaded: loaded (/etc/systemd/system/daemontools.service; disabled)
   Active: active (running) since Fri 2014-07-04 14:55:02 CEST; 2s ago
     Docs: man:svscan(8)
 Main PID: 16950 (svscan)
   CGroup: /system.slice/daemontools.service
           ├─16950 /usr/bin/svscan /etc/service
           ├─16951 supervise sleep
           ├─16952 /bin/bash ./run
           └─16953 sleep 60

Jul 04 14:55:02 snout systemd[1]: Starting daemontools service
supervision...
Jul 04 14:55:02 snout systemd[1]: Started daemontools service supervision.
-----------------------------------------------------------------------

As far as I know, this still misses the maintainer script logic that is
needed to start the service on installation and stop it again when the
package is removed.

There is a debhelper addon to add them, but the daemontools doesn't use
debhelper so they have to be added manually. The snippets can be found
in autoscripts/* in the init-system-helpers source package (it also
needs a runtime dependency on init-system-helpers).

Ansgar

Message #65 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Joern Heissler <debbugs@joern.heissler.de>, 752075@bugs.debian.org

Cc: pkg-systemd-maintainers@lists.alioth.debian.org

Subject: Re: RFH: Re: Bug#752075: daemontools-run: Add systemd support

Date: Fri, 04 Jul 2014 15:49:19 +0200

[Message part 1 (text/plain, inline)]

Am 04.07.2014 14:34, schrieb Michael Biebl:
> Hi Gerrit,
> 
> Am 04.07.2014 13:50, schrieb Gerrit Pape:
>> I hereby ask for help to add systemd support to these packages.
> 
> We (pkg-systemd team) can help you with that.
> 
> Let's follow up on the pkg-systemd mailing list.
> 
> In most cases adding a .service file is pretty simple.
> If it's only about starting a svscanboot process, that might be as
> simple as installing a file
> /lib/systemd/system/svscanboot.service containing
> 
> [Unit]
> Description=daemon tools
> 
> [Service]
> ExecStart=/usr/bin/svscanboot
> Restart=always
> 
> [Install]
> WantedBy=multi-user.target
> 

Joern, could you copy the attached file to /etc/systemd/system, run

systemctl enable svscanboot.service


and report back if your daemontools services are properly started on the
next reboot.

I don't use daemontools myself, so it would be great if Gerrit and you
can provide more input on what kind of services need to be started or if
the attached service file might already be sufficient.

If that is the case, we just need to hook it up so the .service file is
enabled on installation. That can easily be done via dh-systemd.



Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[svscanboot.service (text/plain, attachment)]

[signature.asc (application/pgp-signature, attachment)]

Message #70 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Joern Heissler <debbugs@joern.heissler.de>

To: Michael Biebl <biebl@debian.org>, 752075@bugs.debian.org

Subject: Re: RFH: Re: Bug#752075: daemontools-run: Add systemd support

Date: Sat, 5 Jul 2014 12:28:28 +0200

On Fri, Jul 04, 2014 at 03:49:19PM +0200, Michael Biebl wrote:
> Joern, could you copy the attached file to /etc/systemd/system, run
> 
> systemctl enable svscanboot.service
> 
> and report back if your daemontools services are properly started on the
> next reboot.
> 
> I don't use daemontools myself, so it would be great if Gerrit and you
> can provide more input on what kind of services need to be started or if
> the attached service file might already be sufficient.

Thanks, works for me!

Message #77 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Jonathan de Boyne Pollard <j.deboynepollard-newsgroups@ntlworld.com>, Russ Allbery <eagle@eyrie.org>, Gerrit Pape <pape@dbnbgs.smarden.org>, 752075@bugs.debian.org

Subject: Re: Bug#752075: daemontools-run: Add systemd support

Date: Mon, 07 Jul 2014 14:59:05 +0200

[Message part 1 (text/plain, inline)]

[CCing the bug report]

Am 07.07.2014 14:39, schrieb Jonathan de Boyne Pollard:
> I did systemd units for this ages ago.  It's better to do this as two
> units: a "path" unit that watches the service directory and a
> "service" unit that is started when the service directory is found to
> be non-empty.

Makes sense I guess.

  And you don't need svscanboot at all, since systemd's
> journal logs the output of svscan and does it better than
> readproctitle does.

Ansgar suggested using the journal for that as well [1], which sounds
reasonable.

> There are minor variants on these in the nosh-systemd-services
> package, which runs the nosh daemontools-compatibility scanner under
> systemd in a similar (but not quite the same, since nosh has a
> separate socket-activated service manager and a choice of service
> scanners) manner.  For more documentation, install the nosh-guide
> package and read /usr/local/share/doc/nosh/svscan-startup.html .
> 
> For the packages themselves, go to
> http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html
> .  I notice that I've missed off a link to the nosh-systemd-services
> package.  I'll try to fix that as soon as I have the right computer
> accessible.  It's not hard to guess the URL from the other hyperlinks
> there, though.  nosh-systemd-services_1.6_amd64.deb is the package
> name.
> 
> Do systemd units the systemd way, of course.  My unit files here are
> in /etc because they are my local administrator modifications.  Yours
> will have to be in /usr/lib .

In Debian that would be /lib/systemd/system/

  And don't forget to run "systemctl
> preset svscan.path" as part of your package installation process.
> (I've heard rumours that "update-rc.d svscan.path defaults" runs
> "systemctl preset svscan.path" in some testing versions somewhere; but
> I've not witnessed this myself.)

As Ansgar already mentioned, probably the best way to handle that in
Debian is to use the dh-systemd helper.
Unfortuantely the daemontools package doesn't use debhelper, which
complicates that a bit it.

>  jdebp /etc/systemd/system %cat svscan.path
>  [Unit]
>  Description=Daemontools service monitor
> 
>  [Path]
>  DirectoryNotEmpty=/service/
>  Unit=svscan.service

Is that a typo? Is that really a /service top-level directory?
Shouldn't that rather be something like /etc/service?

>  [Install]
>  WantedBy=multi-user.target
>  jdebp /etc/systemd/system %cat svscan.service
>  [Unit]
>  Description=Daemontools service scanner
> 
>  [Service]
>  ExecStart=/usr/bin/svscan /service/
>  Restart=always
> 
>  [Install]
> 

I guess we have enough options now how this can be addressed in
daemontools. A quite literal translation of the inittab entry or a
deeper integration into systemd utilizing the journal and mechanisms
like .path units.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752075#60

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #82 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Gerrit Pape <pape@dbnbgs.smarden.org>

To: Michael Biebl <biebl@debian.org>

Cc: Jonathan de Boyne Pollard <j.deboynepollard-newsgroups@ntlworld.com>, Gerrit Pape <pape@dbnbgs.smarden.org>, 752075@bugs.debian.org

Subject: Re: Bug#752075: daemontools-run: Add systemd support

Date: Mon, 7 Jul 2014 14:36:25 +0000

Hi Michael, thanks for your help.

On Mon, Jul 07, 2014 at 02:59:05PM +0200, Michael Biebl wrote:
> [CCing the bug report]
> 
> Am 07.07.2014 14:39, schrieb Jonathan de Boyne Pollard:
> > I did systemd units for this ages ago.  It's better to do this as two
> > units: a "path" unit that watches the service directory and a
> > "service" unit that is started when the service directory is found to
> > be non-empty.

Hi Jonathan, good to see you're still around.  Thanks for your
contribution.

>   And you don't need svscanboot at all, since systemd's
> > journal logs the output of svscan and does it better than
> > readproctitle does.
> 
> Ansgar suggested using the journal for that as well [1], which sounds
> reasonable.

Is this journal an in-memory-log, or does it write to disk?

>   And don't forget to run "systemctl
> > preset svscan.path" as part of your package installation process.
> > (I've heard rumours that "update-rc.d svscan.path defaults" runs
> > "systemctl preset svscan.path" in some testing versions somewhere; but
> > I've not witnessed this myself.)
> 
> As Ansgar already mentioned, probably the best way to handle that in
> Debian is to use the dh-systemd helper.
> Unfortuantely the daemontools package doesn't use debhelper, which
> complicates that a bit it.

To me, that's not unfortunate. To me, debhelper complicates things.  It
can't be that difficult to enable a service, configure it to be enabled
by default, and vice-versa.

To see what snippets debhelper puts into maintainer scripts, can you
point me to an example package in Debian that installs simple systemd
services, Michael?  I search for files containing systemd in the debian
package directory, but with no applicable result.

Regards, Gerrit.

Message #87 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: 752075@bugs.debian.org, Gerrit Pape <pape@dbnbgs.smarden.org>

Cc: Jonathan de Boyne Pollard <j.deboynepollard-newsgroups@ntlworld.com>

Subject: Re: Bug#752075: daemontools-run: Add systemd support

Date: Mon, 07 Jul 2014 16:56:24 +0200

[Message part 1 (text/plain, inline)]

Am 07.07.2014 16:36, schrieb Gerrit Pape:
> Hi Michael, thanks for your help.
> 
> On Mon, Jul 07, 2014 at 02:59:05PM +0200, Michael Biebl wrote:
>> [CCing the bug report]
>>
>> Am 07.07.2014 14:39, schrieb Jonathan de Boyne Pollard:
>>> I did systemd units for this ages ago.  It's better to do this as two
>>> units: a "path" unit that watches the service directory and a
>>> "service" unit that is started when the service directory is found to
>>> be non-empty.
> 
> Hi Jonathan, good to see you're still around.  Thanks for your
> contribution.
> 
>>   And you don't need svscanboot at all, since systemd's
>>> journal logs the output of svscan and does it better than
>>> readproctitle does.
>>
>> Ansgar suggested using the journal for that as well [1], which sounds
>> reasonable.
> 
> Is this journal an in-memory-log, or does it write to disk?

Depends on the configuration. The default in jessie will be to not log
to disk. We might change that in the future though.

>>   And don't forget to run "systemctl
>>> preset svscan.path" as part of your package installation process.
>>> (I've heard rumours that "update-rc.d svscan.path defaults" runs
>>> "systemctl preset svscan.path" in some testing versions somewhere; but
>>> I've not witnessed this myself.)
>>
>> As Ansgar already mentioned, probably the best way to handle that in
>> Debian is to use the dh-systemd helper.
>> Unfortuantely the daemontools package doesn't use debhelper, which
>> complicates that a bit it.
> 
> To me, that's not unfortunate. To me, debhelper complicates things.  It
> can't be that difficult to enable a service, configure it to be enabled
> by default, and vice-versa.

The problem here is, that you can't rely on systemd being installed, as
it is not mandatory. Therefore we re-implemented the relevant bits in
the init-system-helpers package.

> To see what snippets debhelper puts into maintainer scripts, can you
> point me to an example package in Debian that installs simple systemd
> services, Michael?  I search for files containing systemd in the debian
> package directory, but with no applicable result.

There are many packages which use dh-systemd (basically all packages
depending on init-system-helpers. You can have a look at those.

Also, Ansgar already more or less answered that question at [1]:

> As far as I know, this still misses the maintainer script logic that is
> needed to start the service on installation and stop it again when the
> package is removed.
> 
> There is a debhelper addon to add them, but the daemontools doesn't use
> debhelper so they have to be added manually. The snippets can be found
> in autoscripts/* in the init-system-helpers source package (it also
> needs a runtime dependency on init-system-helpers).

You can copy the relevant bits to your maintainer scripts, but it has
the unfortunate effect that updates of dh-systemd will not automatically
be applied to your package and you'll have to do that manually.




[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752075#60
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #92 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Gerrit Pape <pape@dbnbgs.smarden.org>

To: pkg-systemd-maintainers@lists.alioth.debian.org

Cc: 752075@bugs.debian.org

Subject: Re: Bug#752075: daemontools-run: Add systemd support

Date: Fri, 18 Jul 2014 12:03:41 +0000

Hi, thanks for all the help I already got.

On Mon, Jul 07, 2014 at 04:56:24PM +0200, Michael Biebl wrote:
> Am 07.07.2014 16:36, schrieb Gerrit Pape:
> >> As Ansgar already mentioned, probably the best way to handle that in
> >> Debian is to use the dh-systemd helper.
> >> Unfortuantely the daemontools package doesn't use debhelper, which
> >> complicates that a bit it.
> > 
> > To me, that's not unfortunate. To me, debhelper complicates things.  It
> > can't be that difficult to enable a service, configure it to be enabled
> > by default, and vice-versa.
> 
> The problem here is, that you can't rely on systemd being installed, as
> it is not mandatory. Therefore we re-implemented the relevant bits in
> the init-system-helpers package.
> 
> > To see what snippets debhelper puts into maintainer scripts, can you
> > point me to an example package in Debian that installs simple systemd
> > services, Michael?  I search for files containing systemd in the debian
> > package directory, but with no applicable result.
> 
> There are many packages which use dh-systemd (basically all packages
> depending on init-system-helpers. You can have a look at those.
> 
> Also, Ansgar already more or less answered that question at [1]:
> 
> > As far as I know, this still misses the maintainer script logic that is
> > needed to start the service on installation and stop it again when the
> > package is removed.
> > 
> > There is a debhelper addon to add them, but the daemontools doesn't use
> > debhelper so they have to be added manually. The snippets can be found
> > in autoscripts/* in the init-system-helpers source package (it also
> > needs a runtime dependency on init-system-helpers).
> 
> You can copy the relevant bits to your maintainer scripts, but it has
> the unfortunate effect that updates of dh-systemd will not automatically
> be applied to your package and you'll have to do that manually.

I'm really not keen to add a dependency to daemontools-run, esp. not to
the runit package, just for (un)installing and starting/stopping a
service.

Why isn't it as simple as installing the unit, and then?:

 systemd not installed || start service
 systemd not installed || have service started by default
and
 systemd not installed || stop service
 systemd not installed || have service not started by default

Why do I need a helper for that?

Regards, Gerrit.

Message #97 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Michael Stapelberg <stapelberg@debian.org>

To: Gerrit Pape <pape@dbnbgs.smarden.org>, pkg-systemd-maintainers@lists.alioth.debian.org

Cc: 752075@bugs.debian.org

Subject: Re: Bug#752075: daemontools-run: Add systemd support

Date: Fri, 18 Jul 2014 20:06:11 +0200

Hi Gerrit,

Gerrit Pape <pape@dbnbgs.smarden.org> writes:
> I'm really not keen to add a dependency to daemontools-run, esp. not to
> the runit package, just for (un)installing and starting/stopping a
> service.
I presume you mean init-system-helpers as the dependency you don’t want
to add.

> Why isn't it as simple as installing the unit, and then?:
>
>  systemd not installed || start service
It is as simple as that. deb-systemd-invoke supports policy-rc.d,
though, which your intended example (AIUI) does not. You’d make some
users really unhappy if you break policy-rc.d with your package.

>  systemd not installed || have service started by default
When systemd is not installed, where does the logic for having the
service started by default come from? While the actually relevant part
of that is as simple as creating a symlink, there are some things make
this entire process more complicated. Some of them come from the fact
that the enabled-state needs to be synchronized across init systems,
i.e. what you do in systemd should also work for the
sysvinit-fallback. We’ll most likely get rid of this in the next Debian
release, but for now we still have to support it.

Further, consider this (from the manpage of deb-systemd-helper):

  The "enable" action will only be performed once (when first installing
  the package). On the first "enable", an state file is created which
  will be deleted upon "purge".

…which enables administrators to disable units and not have them
magically re-enabled on the next package upgrade.

Also, the dh-systemd/deb-systemd-helper combination properly handles
mask-after-remove (i.e. remove but not purge).

In general, it’s hugely beneficial to Debian if packages use the same
helpers/debhelper addons to build their maintainer scripts. Bugfixes and
other improvements that we put into i-s-h will propagate to all packages
without coordinating huge updates/fixes. You don’t need to think about
all the intricacies of correctly handling unit files (in Debian!)
because we already did it.

Let me also point out that _every_ system already has i-s-h installed
these days, so there really is no cost in adding this dependency.

-- 
Best regards,
Michael

Message #102 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Gerrit Pape <pape@dbnbgs.smarden.org>

To: pkg-systemd-maintainers@lists.alioth.debian.org

Cc: 752075@bugs.debian.org

Subject: Re: Bug#752075: daemontools-run: Add systemd support

Date: Tue, 22 Jul 2014 12:34:19 +0000

On Fri, Jul 18, 2014 at 12:03:41PM +0000, Gerrit Pape wrote:
> I'm really not keen to add a dependency to daemontools-run, esp. not to
> the runit package, just for (un)installing and starting/stopping a
> service.

Hi, I've now prepared this changeset.  Do you have any comments on it?


Author: Gerrit Pape <pape@smarden.org>
Date:   Tue Jul 22 12:26:42 2014 +0000

      * debian/systemd/daemontools.path, debian/systemd/daemontools.service:
        new; daemontools-run systemd unit files (thx Michael Biebl, Jonathan de
        Boyne Pollard, Milan P. Stanic).
      * debian/rules: install daemontools-run systemd unit files.
      * debian/daemontools-run.postinst, debian/daemontools-run.postrm: enable
        and start, disable and stop respectively daemontools units if systemd
        is process 1.

diff --git a/debian/changelog b/debian/changelog
index 8d124f4..d2d4efc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+daemontools (1:0.76-3.1) UNRELEASED; urgency=low
+
+  * debian/systemd/daemontools.path, debian/systemd/daemontools.service:
+    new; daemontools-run systemd unit files (thx Michael Biebl, Jonathan de
+    Boyne Pollard, Milan P. Stanic).
+  * debian/rules: install daemontools-run systemd unit files.
+  * debian/daemontools-run.postinst, debian/daemontools-run.postrm: enable
+    and start, disable and stop respectively, daemontools units if systemd
+    is process 1.
+
+ -- Gerrit Pape <pape@smarden.org>  Tue, 22 Jul 2014 14:00:45 +0200
+
 daemontools (1:0.76-3) unstable; urgency=low
 
   * debian/daemontools-run.postinst: don't exec into the kill program, so
diff --git a/debian/daemontools-run.postinst b/debian/daemontools-run.postinst
index d51ac09..1d7aae1 100644
--- a/debian/daemontools-run.postinst
+++ b/debian/daemontools-run.postinst
@@ -74,3 +74,7 @@ if ! grep '^SV:' /etc/inittab >/dev/null; then
   mv -f /etc/inittab'{new}' /etc/inittab
   kill -s HUP 1
 fi
+if test "$(readlink /sbin/init || :)" = /lib/systemd/systemd; then
+  systemctl enable -f daemontools.path
+  systemctl start daemontools.path
+fi
diff --git a/debian/daemontools-run.postrm b/debian/daemontools-run.postrm
index 683e8dc..04f5299 100644
--- a/debian/daemontools-run.postrm
+++ b/debian/daemontools-run.postrm
@@ -16,3 +16,10 @@ if grep -q "#-- daemontools-run begin" /etc/inittab; then
   echo 'Sending log services the TERM and CONT signals...'
   svc -dx /etc/service/*/log || :
 fi
+if test "$(readlink /sbin/init || :)" = /lib/systemd/systemd; then
+  systemctl disable daemontools.path
+  ! systemctl is-active daemontools.path >/dev/null ||
+    systemctl stop daemontools.path
+  ! systemctl is-active daemontools.service >/dev/null ||
+    systemctl stop daemontools.service
+fi
diff --git a/debian/rules b/debian/rules
index eeab545..d7ff9c0 100755
--- a/debian/rules
+++ b/debian/rules
@@ -63,6 +63,10 @@ install-indep: deb-checkdir deb-checkuid
 	install -d -m0755 '$(DIR)'-run/usr/share/man/man8
 	install -m0644 debian/update-service.8 '$(DIR)'-run/usr/share/man/man8/
 	gzip -9 '$(DIR)'-run/usr/share/man/man8/update-service.8
+	#  systemd units
+	install -d -m0755 '$(DIR)'-run/lib/systemd/system
+	install -m0644 debian/systemd/daemontools.* \
+	  '$(DIR)'-run/lib/systemd/system/
 	#  changelog
 	test -r changelog || ln -s daemontools-0.76/src/CHANGES changelog
 
diff --git a/debian/systemd/daemontools.path b/debian/systemd/daemontools.path
new file mode 100644
index 0000000..97ca37b
--- /dev/null
+++ b/debian/systemd/daemontools.path
@@ -0,0 +1,9 @@
+[Unit]
+Description=Daemontools service monitor
+
+[Path]
+DirectoryNotEmpty=/etc/service/
+Unit=daemontools.service
+
+[Install]
+WantedBy=multi-user.target
diff --git a/debian/systemd/daemontools.service b/debian/systemd/daemontools.service
new file mode 100644
index 0000000..077e6ab
--- /dev/null
+++ b/debian/systemd/daemontools.service
@@ -0,0 +1,8 @@
+[Unit]
+Description=Daemontools service scanner
+
+[Service]
+ExecStart=/usr/bin/svscanboot /etc/service/
+Restart=always
+
+[Install]

Message #107 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <email@michaelbiebl.de>

To: Gerrit Pape <pape@dbnbgs.smarden.org>, pkg-systemd-maintainers@lists.alioth.debian.org

Cc: 752075@bugs.debian.org

Subject: Re: Bug#752075: daemontools-run: Add systemd support

Date: Tue, 22 Jul 2014 15:03:02 +0200

[Message part 1 (text/plain, inline)]

Am 22.07.2014 14:34, schrieb Gerrit Pape:
> On Fri, Jul 18, 2014 at 12:03:41PM +0000, Gerrit Pape wrote:
>> I'm really not keen to add a dependency to daemontools-run, esp. not to
>> the runit package, just for (un)installing and starting/stopping a
>> service.
> 
> Hi, I've now prepared this changeset.  Do you have any comments on it?
> 
> 
> Author: Gerrit Pape <pape@smarden.org>
> Date:   Tue Jul 22 12:26:42 2014 +0000
> 
>       * debian/systemd/daemontools.path, debian/systemd/daemontools.service:
>         new; daemontools-run systemd unit files (thx Michael Biebl, Jonathan de
>         Boyne Pollard, Milan P. Stanic).
>       * debian/rules: install daemontools-run systemd unit files.
>       * debian/daemontools-run.postinst, debian/daemontools-run.postrm: enable
>         and start, disable and stop respectively daemontools units if systemd
>         is process 1.
> 
> diff --git a/debian/changelog b/debian/changelog
> index 8d124f4..d2d4efc 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,15 @@
> +daemontools (1:0.76-3.1) UNRELEASED; urgency=low
> +
> +  * debian/systemd/daemontools.path, debian/systemd/daemontools.service:
> +    new; daemontools-run systemd unit files (thx Michael Biebl, Jonathan de
> +    Boyne Pollard, Milan P. Stanic).
> +  * debian/rules: install daemontools-run systemd unit files.
> +  * debian/daemontools-run.postinst, debian/daemontools-run.postrm: enable
> +    and start, disable and stop respectively, daemontools units if systemd
> +    is process 1.
> +
> + -- Gerrit Pape <pape@smarden.org>  Tue, 22 Jul 2014 14:00:45 +0200
> +
>  daemontools (1:0.76-3) unstable; urgency=low
>  
>    * debian/daemontools-run.postinst: don't exec into the kill program, so
> diff --git a/debian/daemontools-run.postinst b/debian/daemontools-run.postinst
> index d51ac09..1d7aae1 100644
> --- a/debian/daemontools-run.postinst
> +++ b/debian/daemontools-run.postinst
> @@ -74,3 +74,7 @@ if ! grep '^SV:' /etc/inittab >/dev/null; then
>    mv -f /etc/inittab'{new}' /etc/inittab
>    kill -s HUP 1
>  fi
> +if test "$(readlink /sbin/init || :)" = /lib/systemd/systemd; then
> +  systemctl enable -f daemontools.path
> +  systemctl start daemontools.path
> +fi

The canonical check if systemd is PID 1 is

"test -d /run/systemd/system"



That said, the logic you added is incomplete/broken in several ways:

The user first installs daemontools-run, later on systemd => the
daemon-tools service will not be enabled


The user deinstalls systemd. Later on he deinstalls daemontools-run =>
the symlinks will not be cleaned up.


The systemctl enable call is run on every update. => If the admin has
disabled the service, it will be re-enabled


I didn't look further. There are probably more cases your maintainer
scripts don't handle correctly.


There is a reason, why we added the logic in a single place.




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #112 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: pkg-systemd-maintainers@lists.alioth.debian.org, 752075@bugs.debian.org, Gerrit Pape <pape@dbnbgs.smarden.org>

Subject: Re: Bug#752075: daemontools-run: Add systemd support

Date: Tue, 22 Jul 2014 15:18:02 +0200

[Message part 1 (text/plain, inline)]

Am 22.07.2014 14:34, schrieb Gerrit Pape:
> On Fri, Jul 18, 2014 at 12:03:41PM +0000, Gerrit Pape wrote:

> --- /dev/null
> +++ b/debian/systemd/daemontools.path
> @@ -0,0 +1,9 @@
> +[Unit]
> +Description=Daemontools service monitor
> +
> +[Path]
> +DirectoryNotEmpty=/etc/service/
> +Unit=daemontools.service
> +
> +[Install]
> +WantedBy=multi-user.target

the .path unit should be hooked up in paths.target.

> diff --git a/debian/systemd/daemontools.service b/debian/systemd/daemontools.service
> new file mode 100644
> index 0000000..077e6ab
> --- /dev/null
> +++ b/debian/systemd/daemontools.service
> @@ -0,0 +1,8 @@
> +[Unit]
> +Description=Daemontools service scanner
> +
> +[Service]
> +ExecStart=/usr/bin/svscanboot /etc/service/

What about Ansgar's improvements/suggestions [1]?
E.g. adding a Documentation= header, directly using svscan, etc?


> +Restart=always
> +
> +[Install]

This seems to be a stray [Install] section?

You can either remove it or better add a Also=daemontools.path there.

This way, if someone runs
"systemctl enable daemontools.service", the corresponding path unit will
be enabled.




[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752075#60
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #117 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Gerrit Pape <pape@dbnbgs.smarden.org>

To: pkg-systemd-maintainers@lists.alioth.debian.org

Cc: 752075@bugs.debian.org

Subject: Re: Bug#752075: daemontools-run: Add systemd support

Date: Tue, 22 Jul 2014 14:20:23 +0000

On Tue, Jul 22, 2014 at 03:03:02PM +0200, Michael Biebl wrote:
> Am 22.07.2014 14:34, schrieb Gerrit Pape:
> > Hi, I've now prepared this changeset.  Do you have any comments on it?

> > diff --git a/debian/daemontools-run.postinst b/debian/daemontools-run.postinst
> > index d51ac09..1d7aae1 100644
> > --- a/debian/daemontools-run.postinst
> > +++ b/debian/daemontools-run.postinst
> > @@ -74,3 +74,7 @@ if ! grep '^SV:' /etc/inittab >/dev/null; then
> >    mv -f /etc/inittab'{new}' /etc/inittab
> >    kill -s HUP 1
> >  fi
> > +if test "$(readlink /sbin/init || :)" = /lib/systemd/systemd; then
> > +  systemctl enable -f daemontools.path
> > +  systemctl start daemontools.path
> > +fi
> 
> The canonical check if systemd is PID 1 is
> 
> "test -d /run/systemd/system"

Thanks.

> That said, the logic you added is incomplete/broken in several ways:
> 
> The user first installs daemontools-run, later on systemd => the
> daemon-tools service will not be enabled

How can I achieve this without calling systemctl?  Creating the symlink
to /etc/systemd/system/... manually, unconditionally?

> The user deinstalls systemd. Later on he deinstalls daemontools-run =>
> the symlinks will not be cleaned up.

So I should create and remove the symlinks unconditionally then, without
using systemctl.

> The systemctl enable call is run on every update. => If the admin has
> disabled the service, it will be re-enabled

Yes, the daemontools-run package is the very service, to disable it, the
package is removed.

> I didn't look further. There are probably more cases your maintainer
> scripts don't handle correctly.
> 
> 
> There is a reason, why we added the logic in a single place.

With sysvinit I have the logic easily implemented in the maintainer
scripts.  With runit it's even more simple.  I really don't want to
depend on some complex logic and an additional package just to have a
service as simple as the daemontools' one installed and always running,
think the inittab approach.

Regards, Gerrit.

Message #122 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Michael Stapelberg <stapelberg@debian.org>

To: Gerrit Pape <pape@dbnbgs.smarden.org>, pkg-systemd-maintainers@lists.alioth.debian.org

Cc: 752075@bugs.debian.org

Subject: Re: Bug#752075: daemontools-run: Add systemd support

Date: Tue, 22 Jul 2014 18:11:24 +0200

Hi Gerrit,

Gerrit Pape <pape@dbnbgs.smarden.org> writes:
>> There is a reason, why we added the logic in a single place.
>
> With sysvinit I have the logic easily implemented in the maintainer
> scripts.  With runit it's even more simple.  I really don't want to
> depend on some complex logic and an additional package just to have a
> service as simple as the daemontools' one installed and always running,
> think the inittab approach.
I’m not sure how we can state this more clearly:

Use dh-systemd or you _will_ have bugs sooner or later. It is the most
simple implementation that we could come up with.

-- 
Best regards,
Michael

Message #127 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Gerrit Pape <pape@dbnbgs.smarden.org>

To: pkg-systemd-maintainers@lists.alioth.debian.org

Cc: 752075@bugs.debian.org

Subject: Re: Bug#752075: daemontools-run: Add systemd support

Date: Sat, 26 Jul 2014 13:21:52 +0000

On Tue, Jul 22, 2014 at 03:03:02PM +0200, Michael Biebl wrote:
> Am 22.07.2014 14:34, schrieb Gerrit Pape:
> > On Fri, Jul 18, 2014 at 12:03:41PM +0000, Gerrit Pape wrote:
> >> I'm really not keen to add a dependency to daemontools-run, esp. not to
> >> the runit package, just for (un)installing and starting/stopping a
> >> service.
> > Hi, I've now prepared this changeset.  Do you have any comments on it?
> That said, the logic you added is incomplete/broken in several ways:

Hi, I'm about to upload these changes:


Author: Gerrit Pape <pape@smarden.org>
Date:   Tue Jul 22 12:26:42 2014 +0000

      * debian/systemd/daemontools.service: new; daemontools-run systemd unit
        file (thx Michael Biebl, Jonathan de Boyne Pollard, Milan P. Stanic).
      * debian/rules: install daemontools-run systemd unit file.
      * debian/daemontools-run.postinst, debian/daemontools-run.postrm: enable
        and start, disable and stop respectively, daemontools unit if systemd
        is process 1 (closes: #752075).

diff --git a/debian/changelog b/debian/changelog
index 8d124f4..a7b7d0e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+daemontools (1:0.76-4) unstable; urgency=low
+
+  * debian/systemd/daemontools.service: new; daemontools-run systemd unit
+    file (thx Michael Biebl, Jonathan de Boyne Pollard, Milan P. Stanic).
+  * debian/rules: install daemontools-run systemd unit file.
+  * debian/daemontools-run.postinst, debian/daemontools-run.postrm: enable
+    and start, disable and stop respectively, daemontools unit if systemd
+    is process 1 (closes: #752075).
+
+ -- Gerrit Pape <pape@smarden.org>  Sat, 26 Jul 2014 09:58:37 +0000
+
 daemontools (1:0.76-3) unstable; urgency=low
 
   * debian/daemontools-run.postinst: don't exec into the kill program, so
diff --git a/debian/daemontools-run.postinst b/debian/daemontools-run.postinst
index d51ac09..7c49b06 100644
--- a/debian/daemontools-run.postinst
+++ b/debian/daemontools-run.postinst
@@ -74,3 +74,10 @@ if ! grep '^SV:' /etc/inittab >/dev/null; then
   mv -f /etc/inittab'{new}' /etc/inittab
   kill -s HUP 1
 fi
+
+# systemd service
+test -h /etc/systemd/system/multi-user.target.wants/daemontools.service ||
+  test ! -d /etc/systemd/system/multi-user.target.wants ||
+    ln -s /lib/systemd/system/daemontools.service \
+      /etc/systemd/system/multi-user.target.wants/
+test ! -d /run/systemd/system || systemctl start daemontools.service
diff --git a/debian/daemontools-run.postrm b/debian/daemontools-run.postrm
index 683e8dc..d27eef5 100644
--- a/debian/daemontools-run.postrm
+++ b/debian/daemontools-run.postrm
@@ -16,3 +16,9 @@ if grep -q "#-- daemontools-run begin" /etc/inittab; then
   echo 'Sending log services the TERM and CONT signals...'
   svc -dx /etc/service/*/log || :
 fi
+
+# systemd service
+test ! -d /run/systemd/system ||
+  ! systemctl is-active daemontools.service >/dev/null ||
+    systemctl stop daemontools.service
+rm -f /etc/systemd/system/multi-user.target.wants/daemontools.service
diff --git a/debian/rules b/debian/rules
index eeab545..21fb57c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -63,6 +63,10 @@ install-indep: deb-checkdir deb-checkuid
 	install -d -m0755 '$(DIR)'-run/usr/share/man/man8
 	install -m0644 debian/update-service.8 '$(DIR)'-run/usr/share/man/man8/
 	gzip -9 '$(DIR)'-run/usr/share/man/man8/update-service.8
+	#  systemd service
+	install -d -m0755 '$(DIR)'-run/lib/systemd/system
+	install -m0644 debian/systemd/daemontools.service \
+	  '$(DIR)'-run/lib/systemd/system/
 	#  changelog
 	test -r changelog || ln -s daemontools-0.76/src/CHANGES changelog
 
diff --git a/debian/systemd/daemontools.service b/debian/systemd/daemontools.service
new file mode 100644
index 0000000..09d9228
--- /dev/null
+++ b/debian/systemd/daemontools.service
@@ -0,0 +1,9 @@
+[Unit]
+Description=Daemontools service supervision
+
+[Service]
+ExecStart=/usr/bin/svscanboot /etc/service/
+Restart=always
+
+[Install]
+WantedBy=multi-user.target

Message #132 received at 752075-close@bugs.debian.org (full text, mbox, reply):

From: Gerrit Pape <pape@smarden.org>

To: 752075-close@bugs.debian.org

Subject: Bug#752075: fixed in daemontools 1:0.76-4

Date: Sun, 27 Jul 2014 21:19:34 +0000

Source: daemontools
Source-Version: 1:0.76-4

We believe that the bug you reported is fixed in the latest version of
daemontools, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 752075@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Gerrit Pape <pape@smarden.org> (supplier of updated daemontools package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Sat, 26 Jul 2014 09:58:37 +0000
Source: daemontools
Binary: daemontools daemontools-run
Architecture: all source
Version: 1:0.76-4
Distribution: unstable
Urgency: low
Maintainer: Gerrit Pape <pape@smarden.org>
Changed-By: Gerrit Pape <pape@smarden.org>
Description:
 daemontools - a collection of tools for managing UNIX services
 daemontools-run - daemontools service supervision
Closes: 752075
Changes:
 daemontools (1:0.76-4) unstable; urgency=low
 .
   * debian/systemd/daemontools.service: new; daemontools-run systemd unit
     file (thx Michael Biebl, Jonathan de Boyne Pollard, Milan P. Stanic).
   * debian/rules: install daemontools-run systemd unit file.
   * debian/daemontools-run.postinst, debian/daemontools-run.postrm: enable
     and start, disable and stop respectively, daemontools unit if systemd
     is process 1 (closes: #752075).
Checksums-Sha1:
 8766d3c611dce7891556b94f392c7d267643f0e9 1037 daemontools_0.76-4.dsc
 b4f331d4206fe57e8865d6a8054048d981ee12cb 17091 daemontools_0.76-4.diff.gz
 c5a6bc9761e65a043c3a7bc06b1abbad820294a8 9642 daemontools-run_0.76-4_all.deb
Checksums-Sha256:
 75dfc75331f103884b32e6fcab480b33ee7b7f2a3002e734e5ebd4ed60dbb8e7 1037 daemontools_0.76-4.dsc
 4eb3b7c70596a9013076fd487eed98b5c83954edf89706fc7804215a31bebf32 17091 daemontools_0.76-4.diff.gz
 ed970f4f377900530fadc310f318c1eda5b3acb7a0bf683bf5837162d5a5b9c0 9642 daemontools-run_0.76-4_all.deb
Files:
 f3939d713d7e20851f69f5aeb2a85088 9642 admin optional daemontools-run_0.76-4_all.deb
 9244c1f934dba04def9def32ff0f1f75 1037 admin optional daemontools_0.76-4.dsc
 71474077372167d88ff0ecac96bf9333 17091 admin optional daemontools_0.76-4.diff.gz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlPVYkYACgkQGJoyQbxwpv9HoQCaAyw/WvnT+JMcZrm/lGXo2BhU
INEAnjhazG9eyafVzddjFIC1LNyPSUis
=MOX+
-----END PGP SIGNATURE-----

Message #137 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Gerrit Pape <pape@dbnbgs.smarden.org>, pkg-systemd-maintainers@lists.alioth.debian.org

Cc: 752075@bugs.debian.org

Subject: Re: Bug#752075: daemontools-run: Add systemd support

Date: Mon, 28 Jul 2014 14:36:06 +0200

[Message part 1 (text/plain, inline)]

Am 26.07.2014 15:21, schrieb Gerrit Pape:
> On Tue, Jul 22, 2014 at 03:03:02PM +0200, Michael Biebl wrote:
>> Am 22.07.2014 14:34, schrieb Gerrit Pape:
>>> On Fri, Jul 18, 2014 at 12:03:41PM +0000, Gerrit Pape wrote:
>>>> I'm really not keen to add a dependency to daemontools-run, esp. not to
>>>> the runit package, just for (un)installing and starting/stopping a
>>>> service.
>>> Hi, I've now prepared this changeset.  Do you have any comments on it?
>> That said, the logic you added is incomplete/broken in several ways:
> 
> Hi, I'm about to upload these changes:

There are still various issues with the maintainer scripts code [1] and
I see you dropped the .path unit again?

Since you are going to do it "your way" anyway I'm not sure why you ask
for feedback from us?

It's like talking to a brick wall.

Michael


[1] aside from the fact that negative clauses make it unnecessarily hard
to read.
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #142 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Gerrit Pape <pape@dbnbgs.smarden.org>

To: pkg-systemd-maintainers@lists.alioth.debian.org, 752075@bugs.debian.org

Subject: Re: Bug#752075: daemontools-run: Add systemd support

Date: Tue, 29 Jul 2014 10:59:49 +0000

Hi Michael,

On Fri, Jul 18, 2014 at 08:06:11PM +0200, Michael Stapelberg wrote:
> Gerrit Pape <pape@dbnbgs.smarden.org> writes:
> > I'm really not keen to add a dependency to daemontools-run, esp. not to
> > the runit package, just for (un)installing and starting/stopping a
> > service.
> I presume you mean init-system-helpers as the dependency you don???t want
> to add.

Any dependency:
$ apt-cache show runit |grep ^Depends
$ apt-cache show daemontools-run |grep ^Depends
Depends: daemontools (>> 1:0.76)
$ apt-cache show daemontools |grep ^Depends
Depends: libc6 (>= 2.7-1)
$ 

> > Why isn't it as simple as installing the unit, and then?:
> >
> >  systemd not installed || start service
> It is as simple as that. deb-systemd-invoke supports policy-rc.d,
> though, which your intended example (AIUI) does not. You???d make some
> users really unhappy if you break policy-rc.d with your package.

I don't think so.  The daemontools-run and runit packages don't include
init scripts.  policy-rc.d never had an effect on them, so nothing will
break.

> >  systemd not installed || have service started by default
> When systemd is not installed, where does the logic for having the
> service started by default come from? While the actually relevant part
> of that is as simple as creating a symlink, there are some things make
> this entire process more complicated. Some of them come from the fact

I hope this "as simple as creating a symlink" works out.

> that the enabled-state needs to be synchronized across init systems,
> i.e. what you do in systemd should also work for the
> sysvinit-fallback.

This is not necessary for the packages in question.  They have an inittab
entry since many years
 SV:123456:respawn:/usr/sbin/runsvdir-start
The whole purpose of the packages is to provide this service, no
"enabled-state" is needed.

$ apt-cache show runit |grep ^Description-en
Description-en: system-wide service supervision
$ apt-cache show daemontools-run |grep ^Description-en
Description-en: daemontools service supervision
$

> Further, consider this (from the manpage of deb-systemd-helper):
> 
>   The "enable" action will only be performed once (when first installing
>   the package). On the first "enable", an state file is created which
>   will be deleted upon "purge".
> 
> ???which enables administrators to disable units and not have them
> magically re-enabled on the next package upgrade.

See above, I don't think this applies.

> Also, the dh-systemd/deb-systemd-helper combination properly handles
> mask-after-remove (i.e. remove but not purge).

Anything wrong in this regard with my current implementation?

> In general, it???s hugely beneficial to Debian if packages use the same
> helpers/debhelper addons to build their maintainer scripts. Bugfixes and
> other improvements that we put into i-s-h will propagate to all packages
> without coordinating huge updates/fixes. You don???t need to think about
> all the intricacies of correctly handling unit files (in Debian!)
> because we already did it.

We're different individuals in Debian and have different opinions.  To
me it's beneficial to Debian if there still exist packages not using
debhelper, doing things differently than others, even than the masses,
following KISS.  I want to think about and understand how the inittab
entry
 SV:123456:respawn:/usr/sbin/runsvdir-start
translates most easily into a systemd service, now that I learned that
this is necessary because systemd doesn't provide backward compatibility
for such services.

> Let me also point out that _every_ system already has i-s-h installed
> these days, so there really is no cost in adding this dependency.

That's not true.  Just a few of my systems have this package pulled in,
all of them have runit installed.

Regards, Gerrit.

Message #147 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Gerrit Pape <pape@dbnbgs.smarden.org>

To: pkg-systemd-maintainers@lists.alioth.debian.org, 752075@bugs.debian.org

Subject: Re: Bug#752075: daemontools-run: Add systemd support

Date: Tue, 29 Jul 2014 11:13:19 +0000

On Mon, Jul 28, 2014 at 02:36:06PM +0200, Michael Biebl wrote:
> Since you are going to do it "your way" anyway I'm not sure why you ask
> for feedback from us?
> 
> It's like talking to a brick wall.

Hi, I'm sorry that you feel this way.  I also found our communication
far from ideal, and after I refused to add a dependency to the
daemontools-run and runit packages, it failed completely.  To me this
feels like do it your way, or no way.

Since you're the specialists, there's still hope to get feedback other
than
On Tue, Jul 22, 2014 at 03:03:02PM +0200, Michael Biebl wrote:
> There is a reason, why we added the logic in a single place.
On Tue, Jul 22, 2014 at 06:11:24PM +0200, Michael Stapelberg wrote:
> I'm not sure how we can state this more clearly:
> Use dh-systemd or you _will_ have bugs sooner or later. It is the most
> simple implementation that we could come up with.

There also are reasons for my design choice.

> There are still various issues with the maintainer scripts code [1]

Please tell me which ones.

> [1] aside from the fact that negative clauses make it unnecessarily
> hard to read.

The fact is that people are different.  To me this is most intuitively
to read in set -e scripts.  When does this script stop?:

set -e
true && true
false && false || true
false && false
false && true || true
false && true
false && true || false
true && true || false
true && true && false
true && false && false

> and I see you dropped the .path unit again?
Yes.  I don't understand the question.

On Tue, Jul 22, 2014 at 03:18:02PM +0200, Michael Biebl wrote:
> What about Ansgar's improvements/suggestions [1]?
> E.g. adding a Documentation= header, directly using svscan, etc?

Thanks to Ansgar, I looked at them but currently don't want to do "a bit
more integration into systemd".  KISS and provide the very same software
experience to users of these packages under sysvinit, runit, and
systemd.

Regards, Gerrit.

Message #152 received at 752075@bugs.debian.org (full text, mbox, reply):

From: Gerrit Pape <pape@dbnbgs.smarden.org>

To: pkg-systemd-maintainers@lists.alioth.debian.org, 752075@bugs.debian.org

Subject: Re: Bug#752075: daemontools-run: Add systemd support

Date: Tue, 29 Jul 2014 11:17:25 +0000

Hi Michael,

On Tue, Jul 22, 2014 at 06:11:24PM +0200, Michael Stapelberg wrote:
> I'm not sure how we can state this more clearly:
> 
> Use dh-systemd or you _will_ have bugs sooner or later. It is the most
> simple implementation that we could come up with.

sorry, we have different points of view, and I will definitely not
switch my packages to debhelper.

Sure, most probably there will be bugs sooner or later, considering that
systemd intergration is still under development.  But also for packages
utilizing debhelper, maybe even more more so because the implementation
is more complex.  They'll probably go through binary NMUs.

Regards, Gerrit.

Send a report that this bug log contains spam.