Re: Removing sysV init files

[Felipe Sateler]

On Sun, 17 Jan 2016 02:23:02 +, Jonathan de Boyne Pollard wrote:

> It didn't start because the service unit was wrong.
> 
> A quick check of the log revealed that the service was trying to create
> a local-domain socket at |/run/lirc/lircd| . But there was no
> |/run/lirc/| directory on my system to contain that.  Your systemd units
> didn't make one; and one doesn't appear by telepathy.  (-:

It seems your conversor is slightly wrong: socket units have an implicit 
Before= dependency added to them. How can it possibly 
be that the init-created socket exists at /run/lirc/lircd (because the 
socket unit has started), and /run/lirc doesn't?

Moreover, if the program you have in your system is not properly built 
because it lacks the fd-receiving code, you can hardly expect the units 
that work via a passed-fd works out of the box.

>  Stefan
> Lippers-Hollmann's System 5 rc scripts *do* make this directory,
> however.  They have this near the start:
> 
> [ -d "/run/lirc" ] || mkdir -p "/run/lirc"
> 
> The systemd service unit file way of doing the same thing is:
> 
> [Service]
> RuntimeDirectory=lirc
> 
> So I edited that into your |lircd.service| and had another go.  This
> time I was hit by a problem with "quirks mode" conversion (which I don't
> use all that often).  Since your |lircd| program doesn't actually rely
> upon any systemd quirks as far as I can see, I simply switched to "ideal
> mode" conversion and converted a third time:
> 
> JdeBP /tmp $ convert-systemd-units --no-systemd-quirks
> ./lircd.socket JdeBP /tmp $ sudo system-control start /tmp/lircd
> 
> Now I was hit by the fact that you'd hardwired the pathname
> |/usr/sbin/lircd| into your service unit.

The standard practice would be to fix the ExecStart path at configure 
time (ie, take into account --prefix or similar).



> Both the System 5 rc scripts and the port-supplied NetBSD rc script (in
> |/usr/local/etc/rc.d/lircd|) are parameterized.  Your systemd unit files
> are not.  In particular, note that the NetBSD rc script has this:
> 
> command_args="-d ${lircd_device} ${lircd_config}"
> 
> This means that FreeBSD/PC-BSD users can use their conventional
> |/etc/rc.conf.local| system to configure how the lircd daemon is
> invoked, by setting |lircd_device| and |lircd_config| variables.

This is a common friction point when transitioning from rc scripts to 
systemd. Because in systemv world, rc scripts are programs and not 
configuration files, it becomes handy to add configuration options 
elsewhere. However, systemd units are configuration files themselves, so 
it becomes less interesting[1] to add configuration options. Instead of 
editing the configuration file for the configuration file, edit the first 
configuration file directly.


[1] I don't claim it is never useful. For example, if a service is spread 
into multiple units it can be useful to have a single place to hold all 
the configuration options.

-- 
Saludos,
Felipe Sateler

Re: lirc systemd packaging (Was: Removing sysV init files)

[Simon McVittie]

On 17/01/16 11:36, Alec Leamas wrote:
> On 17/01/16 03:23, Jonathan de Boyne Pollard wrote:
>> A quick check of the log revealed that the service was trying to create
>> a local-domain socket at |/run/lirc/lircd| . But there was no
>> |/run/lirc/| directory on my system to contain that.  Your systemd units
>> didn't make one
> 
> As I stated in previous reply, temporary files are created using the
> tmpfiles.d mechanism (where the .service/.socket files isn't involved in
> any way).

I'm not sure that nosh should claim to support systemd units if it
doesn't either support tmpfiles.d, or depend on a standalone
implementation of the tmpfiles.d "protocol" (that is guaranteed to be
run before systemd units with DefaultDependencies=yes). The tmpfiles.d
mechanism is rather simple, and the ability to assume that tmpfiles.d
entries are supported is one of the factors that contributes to systemd
units being simple and declarative.

S

Re: Removing sysV init files

[Jonathan de Boyne Pollard]

Jonathan de Boyne Pollard:


It didn't start because the service unit was wrong.

A quick check of the log revealed that the service was trying to 
create a local-domain socket at |/run/lirc/lircd| .  But there was no 
|/run/lirc/| directory on my system to contain that.  Your systemd 
units didn't make one; and one doesn't appear by telepathy.  (-:  
Stefan Lippers-Hollmann's System 5 rc scripts *do* make this 
directory, however. [...]



Alec Leamas:

Now, the systemd scripts are the upstream ones, and they are used in 
several distributions. Hence, statements like "they are wrong" in the 
sense that services doesn't start should be taken with some grain of 
salt.  In this case, it seems like the nosh utility doesn't use the 
systemd tmfiles.d mechanisms which is the way to create temporary 
files and directories in the systemd world.


I'd have used that if I'd found one.  I looked, as that's the other way 
of doing this instead of the |RuntimeDirectory| setting.  There's *is 
no* tmpfiles snippet in your source tree, that I could find.  Your 
|/systemd/| subdirectory (at 
http://sourceforge.net/p/lirc/git/ci/master/tree/systemd/) contains only 
unit files, notice; and there's nothing elsewhere that I could find.   
So yes: your service unit files are wrong, or your source tree that you 
give to the world is incomplete.  You don't provide complete 
configuration for a functional system.


Also note that Lennart Poettering would like you to use 
|RuntimeDirectory| for this in preference to tmpfiles snippets, and have 
your program do that in preference to either, since you are configuring 
it to run as the superuser.  So there's an argument, at least from the 
systemd people, that /your daemon//program/ is incomplete.


   http://lists.freedesktop.org/archives/systemd-devel/2013-July/012024.html

I did enjoy the Mouse Trap nature of your lircd-setup service, that I 
looked at when looking for where you could be hiding your creation of 
the |/run/lirc/| directory.  Your lircd service unit pulls in another 
oneshot service unit that in turn invokes a Python program 
(http://sourceforge.net/p/lirc/git/ci/master/tree/tools/lircd-setup), 
which then reads a configuration file for a string, that it in turn 
passes to the POSIX-compatible shell for execution as an arbitrary shell 
command (with superuser privileges, of course). There's definitely a 
middle man to be cut out, there.  Learn from the mistakes in the systemd 
House of Horror.  (-:


   
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/systemd-house-of-horror/

Alec Leamas:

That said, I have sent a question to Stefan about his role here: is 
the maintainer? If so, what is his plans? However, I still havn't got 
any reply on this.



You can actually look the answer to the first question up for yourself:

   https://packages.debian.org/source/sid/lirc

That's how I knew that xe was one of the maintainers.  (-:

lirc systemd packaging (Was: Removing sysV init files)

[Alec Leamas]

On 17/01/16 03:23, Jonathan de Boyne Pollard wrote:
> Michael Biebl:
>
>> I wonder if nosh could be an option for non-linux. According to its
>> website it supports native systemd service files. I have to admit
>> though, I never looked at nosh myself, so I have no idea how far that
>> "systemd support" goes.
>
> This caught my eye, so I thought that I'd demonstrate.  Before  getting
> to what I did, let's clear up some tangential points.
>
> Alec Leamas:
>
>> The systemd setup [for lirc] is three different services, the sysV
>> [setup] one. There is no systemd service directly corresponding to the
>> sysV one.
>
> The Debian revision log says that that's not in fact true.
>
> http://anonscm.debian.org/viewvc/pkg-lirc?view=revision&revision=521
>
> There have been three System 5 rc scripts since May 2014; precisely so
> that there *is* a correspondence between service names, according to the
> commentary.
>
>  From a Debian point of view, I suspect that the answer that you'll get
> from all of the Debian people who actually look into the situation is
> that if Debian Maintainer Stefan Lippers-Hollmann is willing to continue
> doing this work to maintain System 5 rc scripts for your software, you
> should let xem.  (-:

OK, here is two things both covered in my reply in original thread:
- Stefan's role. A statement from him on this would be good.
- We should incorporate reasonable sysV patches including those in 
current svn tree in upcoming update, agreed.


> I suggest that you should probably pay more attention to the System 5 rc
> scripts, because your systemd units aren't up to scratch and don't do as
> good a job.  I discovered this by running your |lircd.socket| and
> |lircd.service| unit files through the nosh conversion process and
> seeing what resulted.  Your "bad gut feeling" about your System 5 rc
> files is, ironically, misplaced and should be about your systemd 
mechanisms.


There is certainly two possibilities here: that the systemd scripts are 
wrong, or that the nosh utility fails. I presume that if the scripts 
actually works in the sense that they start the services (which they do) 
we need to take a look at nosh, right?


> Yes the nosh package can take this sort of thing
[snip]


> What resulted was a service that didn't start.  Hence "almost".
>
> JdeBP /tmp $ svstat /tmp/lircd
> /tmp/lircd: stopped since 2016-01-16 23:06:12 +; 2m 1s ago. , 
initially started

> JdeBP /tmp $
>
> It didn't start because the service unit was wrong.

No, it's because nosh fails.

> A quick check of the log revealed that the service was trying to create
> a local-domain socket at |/run/lirc/lircd| . But there was no
> |/run/lirc/| directory on my system to contain that.  Your systemd units
> didn't make one; and one doesn't appear by telepathy.  (-:  Stefan
> Lippers-Hollmann's System 5 rc scripts *do* make this directory,

As I stated in previous reply, temporary files are created using the 
tmpfiles.d mechanism (where the .service/.socket files isn't involved in 
any way).


[upstream hat on] If it would make things easier, we could of course use 
other mechanisms as long as they works if it makes nosh's task easier. 
Patches (upstream!) welcome!


> however.  They have this near the start:
>
> [ -d "/run/lirc" ] || mkdir -p "/run/lirc"
>
> The systemd service unit file way of doing the same thing is:
>
> [Service]
> RuntimeDirectory=lirc

Well, it's a possibility. However, the lirc packaging uses tmpfiles.d.

> So I edited that into your |lircd.service| and had another go.  This
> time I was hit by a problem with "quirks mode" conversion (which I don't
> use all that often).  Since your |lircd| program doesn't actually rely
> upon any systemd quirks as far as I can see, I simply switched to "ideal
> mode" conversion and converted a third time:
>
> JdeBP /tmp $ convert-systemd-units --no-systemd-quirks ./lircd.socket
> JdeBP /tmp $ sudo system-control start /tmp/lircd

Sorry, I don't follow you here. What are these quirks, is it something 
to be used, and then why?


> Now I was hit by the fact that you'd hardwired the pathname
> |/usr/sbin/lircd| into your service unit.  This isn't wrong from a Linux
> systemd operating system perspective.  But I'm doing this on FreeBSD
> (PC-BSD 10.2, in fact) to demonstrate that the nosh toolset very much
> does provide the tools for non-Linux operating systems.  The
> FreeBSD-supplied lircd installs into |/usr/local/sbin |not |/usr/sbin|,
> because that's the rule for non-operating-system stuff.  Fortunately,
> there are at least two ways around this.  I took the one that uses
> |$PATH|. The conversion tool can be told |ExecStart=lircd| and that will
> make a service bundle that will just work for either |/usr/sbin/lircd|
> or |/usr/local/sbin/lircd| .  So I edited that into your |lircd.service|


OK. Isn't this just one of those things we do from time to time when 
packaging stuff?


[upstream hat on] I'd certainly accept a

Re: Removing sysV init files

[Alec Leamas]

Hi!

Thansk for long reply!

On 17/01/16 03:23, Jonathan de Boyne Pollard wrote:

Michael Biebl:


I wonder if nosh could be an option for non-linux. According to its
website it supports native systemd service files.



This caught my eye, so I thought that I'd demonstrate.  Before getting
to what I did, let's clear up some tangential points.




What resulted was a service that didn't start.  Hence "almost".

JdeBP /tmp $ svstat /tmp/lircd
/tmp/lircd: stopped since 2016-01-16 23:06:12 +; 2m 1s ago. , initially 
started
JdeBP /tmp $

It didn't start because the service unit was wrong.

A quick check of the log revealed that the service was trying to create
a local-domain socket at |/run/lirc/lircd| . But there was no
|/run/lirc/| directory on my system to contain that.


Now, the systemd scripts are the upstream ones, and they are used in 
several distributions. Hence, statements like "they are wrong"  in the 
sense that services doesn't start should be taken with some grain of 
salt. In this case, it seems like the nosh utility doesn't use the 
systemd tmfiles.d mechanisms which is the way to create temporary files 
and directories in the systemd world. However, this is not in the 
scripts, and should not be - it's in the rules file.


That said, there is always place for improvements. I'll answer to the 
other issues in a new thread, stay tuned.



There have been three System 5 rc scripts since May 2014; precisely so that 
there is a correspondence between service names, according to the commentary.

From a Debian point of view, I suspect that the answer that you'll get from all 
of the Debian people who actually look into the situation is that if Debian 
Maintainer Stefan Lippers-Hollmann is willing to continue doing this work to 
maintain System 5 rc scripts for your software, you should let xem.  (-:



The basic question is basically already answered: we all agree that the 
systemd scripts should be maintained and reasonable patches accepted.


That said, I have sent a question to Stefan about his role here: is the 
maintainer? If so, what is his plans? However, I still havn't got any 
reply on this.


Despite original address fields I'm not cross-posting.


Cheers!

--alec

Re: Removing sysV init files

[Jonathan de Boyne Pollard]

Michael Biebl:

I wonder if nosh could be an option for non-linux. According to its 
website it supports native systemd service files. I have to admit 
though, I never looked at nosh myself, so I have no idea how far that 
"systemd support" goes.


This caught my eye, so I thought that I'd demonstrate.  Before getting 
to what I did, let's clear up some tangential points.


Alec Leamas:

The systemd setup [for lirc] is three different services, the sysV 
[setup] one. There is no systemd service directly corresponding to the 
sysV one.


The Debian revision log says that that's not in fact true.

   http://anonscm.debian.org/viewvc/pkg-lirc?view=revision&revision=521

There have been three System 5 rc scripts since May 2014; precisely so 
that there *is* a correspondence between service names, according to the 
commentary.


From a Debian point of view, I suspect that the answer that you'll get 
from all of the Debian people who actually look into the situation is 
that if Debian Maintainer Stefan Lippers-Hollmann is willing to continue 
doing this work to maintain System 5 rc scripts for your software, you 
should let xem.  (-:


I suggest that you should probably pay more attention to the System 5 rc 
scripts, because your systemd units aren't up to scratch and don't do as 
good a job.  I discovered this by running your |lircd.socket| and 
|lircd.service| unit files through the nosh conversion process and 
seeing what resulted.  Your "bad gut feeling" about your System 5 rc 
files is, ironically, misplaced and should be about your systemd mechanisms.


Yes the nosh package can take this sort of thing and convert it to 
native form.  There's a detailed worked example of doing so on the nosh 
WWW pages.


   
http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/worked-example.html

For lirc it was almost as easy as:

   JdeBP /tmp $ fetch 
'http://sourceforge.net/p/lirc/git/ci/master/tree/systemd/lircd.socket?format=raw'
 -o lircd.socket
   JdeBP /tmp $ fetch 
'http://sourceforge.net/p/lirc/git/ci/master/tree/systemd/lircd.service?format=raw'
 -o lircd.service
   JdeBP /tmp $ convert-systemd-units ./lircd.socket
   JdeBP /tmp $ sudo system-control start /tmp/lircd

What resulted was a service that didn't start.  Hence "almost".

   JdeBP /tmp $ svstat /tmp/lircd
   /tmp/lircd: stopped since 2016-01-16 23:06:12 +; 2m 1s ago. , initially 
started
   JdeBP /tmp $

It didn't start because the service unit was wrong.

A quick check of the log revealed that the service was trying to create 
a local-domain socket at |/run/lirc/lircd| . But there was no 
|/run/lirc/| directory on my system to contain that.  Your systemd units 
didn't make one; and one doesn't appear by telepathy.  (-:  Stefan 
Lippers-Hollmann's System 5 rc scripts *do* make this directory, 
however.  They have this near the start:


   [ -d "/run/lirc" ] || mkdir -p "/run/lirc"

The systemd service unit file way of doing the same thing is:

   [Service]
   RuntimeDirectory=lirc

So I edited that into your |lircd.service| and had another go.  This 
time I was hit by a problem with "quirks mode" conversion (which I don't 
use all that often).  Since your |lircd| program doesn't actually rely 
upon any systemd quirks as far as I can see, I simply switched to "ideal 
mode" conversion and converted a third time:


   JdeBP /tmp $ convert-systemd-units --no-systemd-quirks ./lircd.socket
   JdeBP /tmp $ sudo system-control start /tmp/lircd

Now I was hit by the fact that you'd hardwired the pathname 
|/usr/sbin/lircd| into your service unit.  This isn't wrong from a Linux 
systemd operating system perspective.  But I'm doing this on FreeBSD 
(PC-BSD 10.2, in fact) to demonstrate that the nosh toolset very much 
does provide the tools for non-Linux operating systems.  The 
FreeBSD-supplied lircd installs into |/usr/local/sbin |not |/usr/sbin|, 
because that's the rule for non-operating-system stuff.  Fortunately, 
there are at least two ways around this.  I took the one that uses 
|$PATH|. The conversion tool can be told |ExecStart=lircd| and that will 
make a service bundle that will just work for either |/usr/sbin/lircd| 
or |/usr/local/sbin/lircd| .  So I edited that into your |lircd.service| 
and had another go.


   JdeBP /tmp $ convert-systemd-units --no-systemd-quirks ./lircd.socket
   JdeBP /tmp $ sudo system-control start /tmp/lircd

And it's up and running, converted from your socket and service units 
into native service bundles, on nosh-managed PC-BSD 10.2.


   JdeBP /tmp $ svstat /tmp/lircd
   /tmp/lircd: running (pid 50174) since 2016-01-16 23:39:56 +; 6s ago.
   JdeBP /tmp $

There are several things that you probably should take note of here.

The converted service bundle uses UCSPI-TCP tools from the toolset to 
set up the listening socket for lircd to inherit. Unfortunately, even 
though this is lirc version 0.9.0, built straight from the FreeBSD port 
today, it doesn't have the code that takes the socket as an 

Re: Removing sysV init files

[Alec Leamas]

On 15/01/16 21:58, Stefan Lippers-Hollmann wrote:

Hi

On 2016-01-15, Alec Leamas wrote:

On 15/01/16 21:06, Michael Biebl wrote:

Am 15.01.2016 um 21:01 schrieb Alec Leamas:

On 15/01/16 19:04, Russ Allbery wrote:

[...]

If the names do not match, you can ship a (static) symlink in the
package, say you have
/etc/init.d/foo and /lib/systemd/system/bar.service.
Then ship a symlink like this
/lib/systemd/system/foo.service → /lib/systemd/system/bar.service


It's more complicated. The systemd setup is three different services,
the sysV one. There is no systemd service  directly corresponding  to
the sysV one.  In other words, here is two things taking place  at once:
a major upgrade + sysV -> systemd.


No, actually it's not more complicated. There are two options to fix/
avoid this:


[snip]

Thanks for all replies! I think the conclusion here is clear: the 
scripts should be kept, possibly with some minimal updates.


Cheers!

--alec

Re: Removing sysV init files

[Jonathan Dowland]

On Fri, Jan 15, 2016 at 10:07:11AM -0500, The Wanderer wrote:
> It's not only about downstreams. What about e.g. Debian-kFreeBSD, or
> Debian-Hurd?

Debian/kFreeBSD is a supported architecture, but Debian-Hurd is currently
unofficial.

Re: Favoring systemd timers over cron files Re: Removing sysV init files

[Alexandre Detiste]

Le vendredi 15 janvier 2016, 21:58:18 Anthony DeRobertis a écrit :
> On 01/15/2016 09:29 PM, Jens Reyer wrote:
> > Does this also work somehow for e.g. foo-daily.service + 
> > foo-daily.timer being favored over /etc/cron.daily/foo? Next to a 
> > foo.service being favored over /etc/init.d/foo. Thanks and greets jre 

Hi,

systemd-cron does that:

https://sources.debian.net/src/systemd-cron/1.5.3-1/src/bin/systemd-crontab-generator.py/#L473

I also wrote a proposal for the policy here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770440

The only thing that systemd-cron needs to close last remaining bugs
is a rewrite in a lower level language with a smaller runtime
(C or C++) there's a rewrite done in Rust; butI have no
idea on how to package that in Debian & the runtime is huge.

That's only about 550 lines of python code to rewrite that
read some textfiles in /etc/cron.d (crontabs)
& output other text files in /run (systemd timers & service);
I'll do that "someday".

Then crontab would need to be spun out of cron.deb so that
it could be shared by two implementations.

> No, it won't work automatically. Cron doesn't look at systemd units. 

Vixie cron could be patched to also work this way to avoid noise in log files.

> You could of course put something like this at the top of your 
> /etc/cron.daily/foo:
> 
> if [ -d /run/systemd/system ]; then
>  exit 0;
> fi
> 

Re: Favoring systemd timers over cron files Re: Removing sysV init files

[Anthony DeRobertis]

On 01/15/2016 09:29 PM, Jens Reyer wrote:
Does this also work somehow for e.g. foo-daily.service + 
foo-daily.timer being favored over /etc/cron.daily/foo? Next to a 
foo.service being favored over /etc/init.d/foo. Thanks and greets jre 


No, it won't work automatically. Cron doesn't look at systemd units. You 
could of course put something like this at the top of your 
/etc/cron.daily/foo:


   if [ -d /run/systemd/system ]; then
exit 0;
   fi

Favoring systemd timers over cron files Re: Removing sysV init files

[Jens Reyer]

On 01/15/2016 09:06 PM, Michael Biebl wrote:
> If your package ships both a systemd service unit and a sysv init
> script, you need to make sure that under systemd the native service file
> is used.
> The easiest way to achieve that is to use the same names for the unit
> file and the init script, i.e.
> /etc/init.d/foo should match /lib/systemd/system/foo.service
> 
> If the names do not match, you can ship a (static) symlink in the
> package, say you have
> /etc/init.d/foo and /lib/systemd/system/bar.service.
> Then ship a symlink like this
> /lib/systemd/system/foo.service → /lib/systemd/system/bar.service

Does this also work somehow for e.g. foo-daily.service + foo-daily.timer
being favored over /etc/cron.daily/foo?
Next to a foo.service being favored over /etc/init.d/foo.

Thanks and greets
jre

Re: Removing sysV init files

[Wookey]

+++ Russ Allbery [2016-01-15 10:04 -0800]:
> Alec Leamas  writes:
> 
> > Given all this: would it be OK to drop the sysV files in a stretch
> > update?

Please don't. Some people still use sysVinit and expect things to work
more-or-less as they did previously.
 
> I feel like removing the sysvinit scripts entirely would be "reverting
> existing support without a compelling reason."  But I also think that
> people who want to use sysvinit (or upstart, or any other init system)
> will have to contribute some support there in the form of bug reports and
> patches, just as with any other non-default configuration in Debian. 

Exactly. We'll submit bugs if we notice breakage. And fixes if they
are sufficiently obvious.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Re: Removing sysV init files

[Michael Biebl]

Am 15.01.2016 um 21:56 schrieb Michael Biebl:
> An example for that is alsa-utils:
> The sysv init script is named
> 
> /etc/init.d/alsa-utils
> 
> The systemd service units:
> /lib/systemd/system/alsa-store.service
> /lib/systemd/system/alsa-state.service
> /lib/systemd/system/alsa-restore.service
> 
> And /lib/systemd/system/alsa-utils.service is a symlink pointing at
> /dev/null.
> 
> 
> Another approach, as e.g. used by openvpn, where /etc/init.d/openvpn
> corresponds to a multitude of systemd service units, is to to use a
> dummy service or target, which represents the old sysv name.

That all said, I can very well understand, if you are concerned about
the additional complexity introduced by this.
If you don't have a single service unit which exactly matches the sysv
init script name, it can get tricky to get right, and blindly shipping a
(user) provided sysv init script in your package can actually break your
systemd service unit in such a case, as systemd would try to start both.


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



signature.asc
Description: OpenPGP digital signature

Re: Removing sysV init files

[Stefan Lippers-Hollmann]

Hi

On 2016-01-15, Alec Leamas wrote:
> On 15/01/16 21:06, Michael Biebl wrote:
> > Am 15.01.2016 um 21:01 schrieb Alec Leamas:  
> >> On 15/01/16 19:04, Russ Allbery wrote:  
[...]
> > If the names do not match, you can ship a (static) symlink in the
> > package, say you have
> > /etc/init.d/foo and /lib/systemd/system/bar.service.
> > Then ship a symlink like this
> > /lib/systemd/system/foo.service → /lib/systemd/system/bar.service  
> 
> It's more complicated. The systemd setup is three different services, 
> the sysV one. There is no systemd service  directly corresponding  to 
> the sysV one.  In other words, here is two things taking place  at once: 
> a major upgrade + sysV -> systemd.

No, actually it's not more complicated. There are two options to fix/ 
avoid this:
- split the old initscript /etc/init.d/lirc into three, e.g.
  /etc/init.d/lircd, /etc/init.d/lircmd and /etc/init.d/irexec
  as I've shown in my previous mail (<20160115214556.25012e2e@mir>).
  This way both systemd and sysvinit have the same services to
  work with and the sysv initscripts are automatically masked on
  a system using systemd, favouring the corresponding systemd units 
  instead.
- XOR approach this as Michael Biebl suggested, keep the old initscript
  as /etc/init.d/lirc and hard-mask it for systemd so (which means 
  systemd won't look at it and use the native systemd units instead, 
  while non-systemd doesn't know about the masking (nor the three native 
  systemd units) and just keeps using the old sysv initscripts as before).

The result is basically the same for both options, but doing the trivial
split achieves the same behaviour for all init systems - which can help
potential future debugging significantly (and is a cleaner/ safer solution
if other init systems would gain basic or partial support for systemd units
(e.g on kfreebsd)).

Regards
Stefan Lippers-Hollmann


pgpKxndgICXp4.pgp
Description: Digitale Signatur von OpenPGP

Re: Removing sysV init files

[Michael Biebl]

Am 15.01.2016 um 21:48 schrieb Michael Biebl:
> Hi Alec
> 
> Am 15.01.2016 um 21:42 schrieb Alec Leamas:
>> It's more complicated. The systemd setup is three different services,
>> the sysV one. There is no systemd service  directly corresponding  to
>> the sysV one.  In other words, here is two things taking place  at once:
>> a major upgrade + sysV -> systemd.
> 
> In that case, I would probably mask the sysv init script under systemd,
> i.e ship a symlink /lib/systemd/systemd/sysvinitname → /dev/null
> 
> This way, it is prevented, that the sysv init script is run (by
> accident) under systemd.

An example for that is alsa-utils:
The sysv init script is named

/etc/init.d/alsa-utils

The systemd service units:
/lib/systemd/system/alsa-store.service
/lib/systemd/system/alsa-state.service
/lib/systemd/system/alsa-restore.service

And /lib/systemd/system/alsa-utils.service is a symlink pointing at
/dev/null.


Another approach, as e.g. used by openvpn, where /etc/init.d/openvpn
corresponds to a multitude of systemd service units, is to to use a
dummy service or target, which represents the old sysv name.

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



signature.asc
Description: OpenPGP digital signature

Re: Removing sysV init files

[Michael Biebl]

Hi Alec

Am 15.01.2016 um 21:42 schrieb Alec Leamas:
> It's more complicated. The systemd setup is three different services,
> the sysV one. There is no systemd service  directly corresponding  to
> the sysV one.  In other words, here is two things taking place  at once:
> a major upgrade + sysV -> systemd.

In that case, I would probably mask the sysv init script under systemd,
i.e ship a symlink /lib/systemd/systemd/sysvinitname → /dev/null

This way, it is prevented, that the sysv init script is run (by
accident) under systemd.


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



signature.asc
Description: OpenPGP digital signature

Re: Removing sysV init files

[Stefan Lippers-Hollmann]

Hi

On 2016-01-15, Alec Leamas wrote:
> On 15/01/16 19:04, Russ Allbery wrote:
> >
> > I feel like removing the sysvinit scripts entirely would be "reverting
> > existing support without a compelling reason."  But I also think that
> > people who want to use sysvinit (or upstart, or any other init system)
> > will have to contribute some support there in the form of bug reports and
> > patches, just as with any other non-default configuration in Debian.  Your
> > obligation as maintainer is to "merge reasonable contributions" as
> > mentioned above.  
> 
> OK, seems that all agree that the scripts should be kept in the package. 
> So the question then becomes how. As you might have understood I have a 
> bad gut feeling about them.
> 
> Given this, would it be OK to put  the sysV scripts in a separate 
> subpackage which can be properly commented?

As Michael Biebl already mentioned, this is overkill (and borderline 
broken, because the hypothetical 'lirc-sysv' won't be pulled in by 
upgrades, thereby breaking kfreebsd-any and hurd).

Working sysv initscripts for lircd/ lircmd/ irexec:

http://anonscm.debian.org/viewvc/pkg-lirc/lirc/trunk/debian/lirc.lircd.init?view=markup
http://anonscm.debian.org/viewvc/pkg-lirc/lirc/trunk/debian/lirc.lircmd.init?view=markup
http://anonscm.debian.org/viewvc/pkg-lirc/lirc/trunk/debian/lirc.irexec.init?view=markup

which are masked by the according, upstream provided, systemd units,
therefore being a no-op on systems using systemd and drop-in 
replacements for systems not using it (respectively not being able
to use systemd yet, namely kfreebsd-amd64, kfreebsd-i386 and hurd).
The maintenance overhead for these is minimal, at least for the time
being, unless there are significant (upstream) changes in the queue 
for lirc and there is little excuse to intentionally break support
for sysvinit (== non-linux ports).

Combined, these three initscripts (including lots of whitespace) are 
5 KB in size, the packaging overhead (/usr/share/doc// and
the space this required in the package indices, e.g. Packages.gz) for 
these would far bigger than the potential gain of stripping them out 
(the only advantage would be being able to drop the dependency on 
lsb-base, a whopping 51 KB installed package size --> not worth it, 
even assuming lsb-base wouldn't be required by many other core packages
anyways).

Regards
Stefan Lippers-Hollmann


pgpPJNl3LgbCu.pgp
Description: Digitale Signatur von OpenPGP

Re: Removing sysV init files

[Alec Leamas]

On 15/01/16 21:06, Michael Biebl wrote:

Am 15.01.2016 um 21:01 schrieb Alec Leamas:

On 15/01/16 19:04, Russ Allbery wrote:


I feel like removing the sysvinit scripts entirely would be "reverting
existing support without a compelling reason."  But I also think that
people who want to use sysvinit (or upstart, or any other init system)
will have to contribute some support there in the form of bug reports and
patches, just as with any other non-default configuration in Debian.
Your
obligation as maintainer is to "merge reasonable contributions" as
mentioned above.


OK, seems that all agree that the scripts should be kept in the package.
So the question then becomes how. As you might have understood I have a
bad gut feeling about them.

Given this, would it be OK to put  the sysV scripts in a separate
subpackage which can be properly commented?



I think a sub package is overkill and up until now, this has been
avoided in Debian.

If your package ships both a systemd service unit and a sysv init
script, you need to make sure that under systemd the native service file
is used.
The easiest way to achieve that is to use the same names for the unit
file and the init script, i.e.
/etc/init.d/foo should match /lib/systemd/system/foo.service

If the names do not match, you can ship a (static) symlink in the
package, say you have
/etc/init.d/foo and /lib/systemd/system/bar.service.
Then ship a symlink like this
/lib/systemd/system/foo.service → /lib/systemd/system/bar.service


It's more complicated. The systemd setup is three different services, 
the sysV one. There is no systemd service  directly corresponding  to 
the sysV one.  In other words, here is two things taking place  at once: 
a major upgrade + sysV -> systemd.


Cheers

--alec

Re: Removing sysV init files

[Michael Biebl]

Am 15.01.2016 um 21:01 schrieb Alec Leamas:
> On 15/01/16 19:04, Russ Allbery wrote:
>>
>> I feel like removing the sysvinit scripts entirely would be "reverting
>> existing support without a compelling reason."  But I also think that
>> people who want to use sysvinit (or upstart, or any other init system)
>> will have to contribute some support there in the form of bug reports and
>> patches, just as with any other non-default configuration in Debian. 
>> Your
>> obligation as maintainer is to "merge reasonable contributions" as
>> mentioned above.
> 
> OK, seems that all agree that the scripts should be kept in the package.
> So the question then becomes how. As you might have understood I have a
> bad gut feeling about them.
> 
> Given this, would it be OK to put  the sysV scripts in a separate
> subpackage which can be properly commented?
> 

I think a sub package is overkill and up until now, this has been
avoided in Debian.

If your package ships both a systemd service unit and a sysv init
script, you need to make sure that under systemd the native service file
is used.
The easiest way to achieve that is to use the same names for the unit
file and the init script, i.e.
/etc/init.d/foo should match /lib/systemd/system/foo.service

If the names do not match, you can ship a (static) symlink in the
package, say you have
/etc/init.d/foo and /lib/systemd/system/bar.service.
Then ship a symlink like this
/lib/systemd/system/foo.service → /lib/systemd/system/bar.service




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



signature.asc
Description: OpenPGP digital signature

Re: Removing sysV init files

[Alec Leamas]

On 15/01/16 19:04, Russ Allbery wrote:


I feel like removing the sysvinit scripts entirely would be "reverting
existing support without a compelling reason."  But I also think that
people who want to use sysvinit (or upstart, or any other init system)
will have to contribute some support there in the form of bug reports and
patches, just as with any other non-default configuration in Debian.  Your
obligation as maintainer is to "merge reasonable contributions" as
mentioned above.


OK, seems that all agree that the scripts should be kept in the package. 
So the question then becomes how. As you might have understood I have a 
bad gut feeling about them.


Given this, would it be OK to put  the sysV scripts in a separate 
subpackage which can be properly commented?



Cheers!

--alec

Re: Removing sysV init files

[Michael Biebl]

Am 15.01.2016 um 16:07 schrieb The Wanderer:
> It's not only about downstreams. What about e.g. Debian-kFreeBSD, or
> Debian-Hurd? Both are theoretically official Debian, as far as I
> understand matters, rather than being downstream distros - but neither
> one is supported by systemd.

I wonder if nosh [1] could be an option for non-linux. According to its
website it supports native systemd service files. I have to admit
though, I never looked at nosh myself, so I have no idea how far that
"systemd support" goes.


Michael


[1] http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Removing sysV init files

[Russ Allbery]

Alec Leamas  writes:

> In the process of a complicated update, there is a question about how to
> handle the systemV init scripts when doing the systemd transition.

> The package (lirc) has upstream systemd scripts which of course are
> packaged. The existing Debian version has sysV scripts. However, these
> are quite a pain to maintain.

> Given all this: would it be OK to drop the sysV files in a stretch
> update?

It sounds like the primary concern you have around keeping the files is
keeping them up-to-date.  If you don't have the resources to do that (or
prefer to spend them on other parts of the package), let me suggest a
third option: ship the sysvinit scripts as-is in the package, and solicit
help from users of the package to update them.  You could put a large
comment at the top of the script plus a notice in changelog saying that
you're happy to keep including the sysvinit scripts, but don't use or test
them yourself, so are entirely reliant on other people submitting fixes.
You can then continue to make any obvious fixes (if the path to some
executable changes, etc.), but if no one steps forward, the more subtle
things are likely to degrade.

We had some really extended discussions about exactly this problem prior
to the init system discussion before the jessie release, and the above
approach seemed to have the most consensus.

I think this is also consistent with the TC decision (#746715):

The issue of init system support recently came to the Technical
Committee's attention again.[1]

For the record, the TC expects maintainers to continue to support
the multiple available init systems in Debian.  That includes
merging reasonable contributions, and not reverting existing
support without a compelling reason.

I feel like removing the sysvinit scripts entirely would be "reverting
existing support without a compelling reason."  But I also think that
people who want to use sysvinit (or upstart, or any other init system)
will have to contribute some support there in the form of bug reports and
patches, just as with any other non-default configuration in Debian.  Your
obligation as maintainer is to "merge reasonable contributions" as
mentioned above.

-- 
Russ Allbery (r...@debian.org)   

Re: Removing sysV init files

[Guus Sliepen]

On Fri, Jan 15, 2016 at 03:45:30PM +0100, Alec Leamas wrote:

> Support for users not using systemd. I understand that such users will be
> unhappy without the scripts - but am I obliged under current policy
> decisions to maintain this configuration?

Up until the next stable release at least, you are strongly advised to
keep the sysvinit files in place. If you cannot maintain them yourself,
ask for help.

> [...] the sysV scripts exists and perhaps "works" in a
> basic sense [...]

That is already much better than not having a SysV script. But at this
point I don't think you have to spend a lot of effort to try to get it
to feature parity with the systemd service. Though if someone sends you
a patch to improve the SysV script, you should accept it.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Re: Removing sysV init files

[The Wanderer]

On 2016-01-15 at 09:45, Alec Leamas wrote:

> On 15/01/16 14:13, Dmitrii Kashin wrote:
> 
>> Alec Leamas  writes:
>> 
>>> Dear list,

>>> Given all this: would it be OK to drop the sysV files in a
>>> stretch update?
>> 
>> I suppose it's not okay, because you'll get a lot of bug reports
>> from non-linux based debian distributions. And if it's not your
>> business, and you don't support sysv scripts, then it will
>> eventually become a problem for developers of these distributions.
>> 
>> I wanna remind that systemd as the default is an experiment. It can
>> be finished in a while. So it's important to safe the support for
>> other init systems.

While I agree with the sentiment, I'm not sure I've heard that choosing
systemd as default was an "experiment" before now, at least any more
than any Debian choice is an experiment (in that the project can decide
to switch away from it if it doesn't work out well).

>> Btw, I'm a user of Debian Jessie, and I see then now Debian keep
>> an ability to work without systemd. I'd like it to be so in the
>> future.
> 
> So, here is three things:
> 
> Support for non-linux based debian distributions. Perhaps this could
> be handled by packing current scripts in /usr/share/doc, so they are
> available for downstream packaging? Besides that, what says policy
> decisions on this issue?

It's not only about downstreams. What about e.g. Debian-kFreeBSD, or
Debian-Hurd? Both are theoretically official Debian, as far as I
understand matters, rather than being downstream distros - but neither
one is supported by systemd.

> Support for users not using systemd. I understand that such users
> will be unhappy without the scripts - but am I obliged under current
> policy decisions to maintain this configuration?

My understanding from the past debates is that you're not obliged to
maintain sysvinit scripts, but that if other people want to do the work
and send in patches to add / update / maintain such scripts, you don't
get to reject them - or at least not on the grounds that sysvinit is not
supported.

That would seem to imply, in turn, that you shouldn't drop existing
sysvinit scripts from the package, unless they're known to already be
broken badly enough that not having any would be an improvement
(although I don't think I've seen this specifically addressed in past
discussions). You wouldn't be obliged to continue to maintain and update
them, however, and IMO - in the absence of someone who _is_ doing that -
you'd be fine to put in a warning that using them is unsupported and not
recommended.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Removing sysV init files

[Alec Leamas]

On 15/01/16 14:13, Dmitrii Kashin wrote:

Alec Leamas  writes:


Dear list,




Given all this: would it be OK to drop the sysV files in a stretch update?


I suppose it's not okay, because you'll get a lot of bug reports from
non-linux based debian distributions. And if it's not your business, and
you don't support sysv scripts, then it will eventually become a problem
for developers of these distributions.

I wanna remind that systemd as the default is an experiment. It can be
finished in a while. So it's important to safe the support for other
init systems.

Btw, I'm a user of Debian Jessie, and I see then now Debian keep an
ability to work without systemd. I'd like it to be so in the future.



So, here is three things:

Support for non-linux based debian distributions. Perhaps this could be 
handled by packing current scripts in /usr/share/doc, so they are 
available for downstream packaging? Besides that, what says policy 
decisions on this issue?


Support for users not using systemd. I understand that such users will 
be unhappy without the scripts - but am I obliged under current policy 
decisions to maintain this configuration?


"systemd is an experiment". Well, the future can bring any changes. 
Frankly, we need to adapt when the changes come, if they come. IMHO, 
what we can about this is, again, to ship the unmaintained scripts in 
/usr/share doc.


I might add that this is not as simple as some service changing from an 
init.d script to a corresponding .service files. The upstream package 
has another service structure, socket activation and other things which 
are not easily reflected in the sysV scripts. Also, all existing 
documentation presumes systemd. So, while the sysV scripts exists and 
perhaps "works" in a  basic sense they represent sub-optimal user 
experience. This is what makes this hard.


Thoughts?


--alec

Re: Removing sysV init files

[Dmitrii Kashin]

Alec Leamas  writes:

> Dear list,
>
> In the process of a complicated update, there is a question about how
> to handle the systemV init scripts when doing the systemd transition.
>
> The package (lirc) has upstream systemd scripts which of course are
> packaged. The existing Debian version has sysV scripts. However, these
> are quite a pain to maintain.
>
> Given all this: would it be OK to drop the sysV files in a stretch update?

I suppose it's not okay, because you'll get a lot of bug reports from
non-linux based debian distributions. And if it's not your business, and
you don't support sysv scripts, then it will eventually become a problem
for developers of these distributions.

I wanna remind that systemd as the default is an experiment. It can be
finished in a while. So it's important to safe the support for other
init systems.

Btw, I'm a user of Debian Jessie, and I see then now Debian keep an
ability to work without systemd. I'd like it to be so in the future.

Removing sysV init files

[Alec Leamas]

Dear list,

In the process of a complicated update, there is a question about how to 
handle the systemV init scripts when doing the systemd transition.


The package (lirc) has upstream systemd scripts which of course are 
packaged. The existing Debian version has sysV scripts. However, these 
are quite a pain to maintain.


Given all this: would it be OK to drop the sysV files in a stretch update?


Cheers!

--alec