Bug#941198: In support of mandatory unit files

[Guillem Jover]

On Sun, 2019-12-08 at 15:55:45 -0800, Russ Allbery wrote:
> Guillem Jover  writes:
> > But here you do have another option, but I'm not sure it might be
> > described as nicer TBH, :) something like this, or variations on this
> > theme:
> 
> >   [Service]
> >   Type=simple
> >   EnvironmentFile=/etc/default/service-static-vars
> >   EnvironmentFile=-/run/service-dynamic-vars
> >   ExecStartPre=-/bin/sh -c 'echo NAME=$(hostname) 
> > >/run/service-dynamic-vars'
> >   ExecStart=/usr/bin/daemon --option ${NAME}
> 
> This is a nice approach, but I don't think it quite preserves the original
> behavior.  As you wrote it above, if someone changed the setting in the
> /etc/default file, that would have no effect and the default would still
> be used.  If you reverse the order of EnvironmentFile, it avoids that
> problem, but now the legacy setting with $(hostname) will be used if it
> hasn't been changed, and that will result in a literal $(hostname) in the
> value.

Right, it was more about showing the concept than a proper
implementation, but it's true that as is, it's not helpful. :)

I guess the following which starts to get a bit into ugly territory
would do instead:

   [Service]
   Type=simple
   EnvironmentFile=-/run/service-dynamic-vars
   ExecStartPre=-/usr/bin/env -i /bin/sh -a -c '. 
/etc/default/service-static-vars && env -uPWD >/run/service-dynamic-vars'
   ExecStart=/usr/bin/daemon --option ${NAME}

Thanks,
Guillem

Bug#941198: In support of mandatory unit files

[Russ Allbery]

Guillem Jover  writes:

> But here you do have another option, but I'm not sure it might be
> described as nicer TBH, :) something like this, or variations on this
> theme:

>   [Service]
>   Type=simple
>   EnvironmentFile=/etc/default/service-static-vars
>   EnvironmentFile=-/run/service-dynamic-vars
>   ExecStartPre=-/bin/sh -c 'echo NAME=$(hostname) >/run/service-dynamic-vars'
>   ExecStart=/usr/bin/daemon --option ${NAME}

This is a nice approach, but I don't think it quite preserves the original
behavior.  As you wrote it above, if someone changed the setting in the
/etc/default file, that would have no effect and the default would still
be used.  If you reverse the order of EnvironmentFile, it avoids that
problem, but now the legacy setting with $(hostname) will be used if it
hasn't been changed, and that will result in a literal $(hostname) in the
value.

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

Bug#941198: In support of mandatory unit files

[Guillem Jover]

On Sun, 2019-12-08 at 11:15:57 -0800, Russ Allbery wrote:
> > Sure, help fir that would be nice. Thanks for the offer.  (Probably
> > should have an own bug for that.) Nethertheless, this is the line that
> > causes my problems and needs to be transferred:
> > https://salsa.debian.org/debian/gmrender-resurrect/blob/master/debian/gmediarender.default#L8
> 
> Ah, I see, the problem is the $(hostname) part, which isn't supported by
> EnvironmentFile in systemd (which is the normal way to solve this
> problem).
> 
> After looking at this for a bit, my inclination if I were you would be to
> write a tiny shell script that loads /etc/default/gmediarender, constructs
> the command line, and then execs the daemon; install that script as
> /usr/share/gmediarender/start; and then invoke that script via
> start-stop-daemon in the init script and via ExecStart in the systemd unit
> file.  It's a little bit overkill because most of what the /etc/default
> file is doing is simple, but it looks like the easiest way to handle
> $(hostname).

I'd avoid using the wrapper for the init script TBH, because even
though that will make this a bit WET, it would otherwise make it more
complex there (having to use --startas and --exec to cope with the
intermediate interpreter usage).

I think shared wrappers make more sense when used to offload some kind of
pre/post "hook" work, which gets called from Exec{Start,Stop}{Pre,Post}
systemd service file directives (and init scripts).

But here you do have another option, but I'm not sure it might be
described as nicer TBH, :) something like this, or variations on this
theme:

  [Service]
  Type=simple
  EnvironmentFile=/etc/default/service-static-vars
  EnvironmentFile=-/run/service-dynamic-vars
  ExecStartPre=-/bin/sh -c 'echo NAME=$(hostname) >/run/service-dynamic-vars'
  ExecStart=/usr/bin/daemon --option ${NAME}

Thanks,
Guillem

Bug#941198: In support of mandatory unit files

[Russ Allbery]

Tobias Frost  writes:
> Am Samstag, den 07.12.2019, 17:12 -0800 schrieb Russ Allbery:

>> A Policy should means that if there is some stronger reason (such as
>> that adding a unit file would introduce new bugs), there is nothing
>> requiring you to do so.  It indicates that not having a unit file is a
>> bug, but it's just a bug, and Debian packages are not expected to be
>> bug- free.  Other bugs may be more important.

> Well, I was responding to a mail that suggested to make unit files
> mandatory (which I read as then RC-buggy) and suggesting some lines
> later to drop support for the sysv-generator and in this case it is
> quite moot that policy can be ignored because I fear that once unit
> files would become mandatory that would be used as an argument to drop
> support for the generator.

Just to be clear, that's not what this bug proposes.  This bug just
proposes making systemd unit files recommended.

> Sure, help fir that would be nice. Thanks for the offer.  (Probably
> should have an own bug for that.) Nethertheless, this is the line that
> causes my problems and needs to be transferred:
> https://salsa.debian.org/debian/gmrender-resurrect/blob/master/debian/gmediarender.default#L8

Ah, I see, the problem is the $(hostname) part, which isn't supported by
EnvironmentFile in systemd (which is the normal way to solve this
problem).

After looking at this for a bit, my inclination if I were you would be to
write a tiny shell script that loads /etc/default/gmediarender, constructs
the command line, and then execs the daemon; install that script as
/usr/share/gmediarender/start; and then invoke that script via
start-stop-daemon in the init script and via ExecStart in the systemd unit
file.  It's a little bit overkill because most of what the /etc/default
file is doing is simple, but it looks like the easiest way to handle
$(hostname).

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

Bug#941198: In support of mandatory unit files

[Simon Richter]

Hi,

On 08.12.19 09:54, Tobias Frost wrote:

> Well, I was responding to a mail that suggested to make unit files
> mandatory (which I read as then RC-buggy) and suggesting some lines
> later to drop support for the sysv-generator and in this case it is
> quite moot that policy can be ignored because I fear that once
> unit files would become mandatory that would be used as an argument to
> drop support for the generator.

The generator that makes the init scripts usable for systemd generates a
unit that calls the init script. It should be possible to just do the
same thing and build a unit file that calls the init script. That would
be fully allowed when unit files are mandatory.

   Simon



signature.asc
Description: OpenPGP digital signature

Bug#941198: In support of mandatory unit files

[Bill Allombert]

On Sun, Dec 08, 2019 at 12:59:25PM -0400, David Bremner wrote:
> Bill Allombert  writes:
> > In any case, this is an upstream choice, not a packaging choice, so we
> > have to use what upstream provide.
>
> Just to be clear using /etc/default is not an upstream choice, it's a
> Debian convention. I know you probably didn't mean to imply that, but
> that's how it read to me.

The context is that some package are configured via setting some
environment variable or command line parameter instead of reading a
config file at start up, and this is precisely the situation when
/etc/default is used.

I argue that whether to use command line parameters or to read a config
file is an upstream choice.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#941198: In support of mandatory unit files

[David Bremner]

Bill Allombert  writes:

>
> In any case, this is an upstream choice, not a packaging choice, so we
> have to use what upstream provide.
>

Just to be clear using /etc/default is not an upstream choice, it's a
Debian convention. I know you probably didn't mean to imply that, but
that's how it read to me.

d

Bug#941198: In support of mandatory unit files

[Andrey Rahmatullin]

On Sun, Dec 08, 2019 at 02:25:41PM +0100, Bill Allombert wrote:
> > > Sure, help fir that would be nice. Thanks for the offer.
> > > (Probably should have an own bug for that.) Nethertheless, this is the
> > > line that causes my problems and needs to be transferred:
> > > https://salsa.debian.org/debian/gmrender-resurrect/blob/master/debian/gmediarender.default#L8
> > I think they way forward is getting rid of .default files. These options
> > belong in software specific conffiles, not in conffiles for initscript
> > conffiles.
> 
> I disagree. The command line / environment is a perfectly valid way to
> set software options. It has a standard and well-understood interface,
> while each configuration files tend to have their own unique syntax and
> parser idiosynchrasy and bogosity. We should have less configuration
> file parsers, not more.
In that case users should edit the unit files directly, configuring the
command directly.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#941198: In support of mandatory unit files

[Bill Allombert]

On Sun, Dec 08, 2019 at 03:02:10PM +0500, Andrey Rahmatullin wrote:
> On Sun, Dec 08, 2019 at 09:54:23AM +0100, Tobias Frost wrote:
> > Sure, help fir that would be nice. Thanks for the offer.
> > (Probably should have an own bug for that.) Nethertheless, this is the
> > line that causes my problems and needs to be transferred:
> > https://salsa.debian.org/debian/gmrender-resurrect/blob/master/debian/gmediarender.default#L8
> I think they way forward is getting rid of .default files. These options
> belong in software specific conffiles, not in conffiles for initscript
> conffiles.

I disagree. The command line / environment is a perfectly valid way to
set software options. It has a standard and well-understood interface,
while each configuration files tend to have their own unique syntax and
parser idiosynchrasy and bogosity. We should have less configuration
file parsers, not more.

In any case, this is an upstream choice, not a packaging choice, so we
have to use what upstream provide.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Bug#941198: In support of mandatory unit files

[Bill Allombert]

On Sat, Dec 07, 2019 at 05:12:14PM -0800, Russ Allbery wrote:
> That said, if you'd like help with this, I or someone else following this
> thread may be willing to take a look and figure out a way to replicate the
> init script behavior.  It's normally possible to handle /etc/default
> conffiles in systemd units, although it can be a little complicated.

If possible, this should be made simple.

Package are supposed to preserve user configuration across upgrade,
so unit files should not simply ignore user change to /etc/default.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#941198: In support of mandatory unit files

[Andrey Rahmatullin]

On Sun, Dec 08, 2019 at 09:54:23AM +0100, Tobias Frost wrote:
> Sure, help fir that would be nice. Thanks for the offer.
> (Probably should have an own bug for that.) Nethertheless, this is the
> line that causes my problems and needs to be transferred:
> https://salsa.debian.org/debian/gmrender-resurrect/blob/master/debian/gmediarender.default#L8
I think they way forward is getting rid of .default files. These options
belong in software specific conffiles, not in conffiles for initscript
conffiles.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#941198: In support of mandatory unit files

[Tobias Frost]

Am Samstag, den 07.12.2019, 17:12 -0800 schrieb Russ Allbery:
> Tobias Frost  writes:
> 
> > JFTR, I maintain gmedia-resurrect and in this package I failed
> > despite
> > trying to create a systemd unit file with equal functinality as the
> > init.d script*.  So for this package the proposoal would lead to
> > regressions for the users.
> 
> A Policy should means that if there is some stronger reason (such as
> that
> adding a unit file would introduce new bugs), there is nothing
> requiring
> you to do so.  It indicates that not having a unit file is a bug, but
> it's
> just a bug, and Debian packages are not expected to be bug-
> free.  Other
> bugs may be more important.

Well, I was responding to a mail that suggested to make unit files
mandatory (which I read as then RC-buggy) and suggesting some lines
later to drop support for the sysv-generator and in this case it is
quite moot that policy can be ignored because I fear that once
unit files would become mandatory that would be used as an argument to
drop support for the generator. 

> That said, if you'd like help with this, I or someone else following
> this
> thread may be willing to take a look and figure out a way to
> replicate the
> init script behavior.  It's normally possible to handle /etc/default
> conffiles in systemd units, although it can be a little complicated.

Sure, help fir that would be nice. Thanks for the offer.
(Probably should have an own bug for that.) Nethertheless, this is the
line that causes my problems and needs to be transferred:
https://salsa.debian.org/debian/gmrender-resurrect/blob/master/debian/gmediarender.default#L8

-- tobi

Bug#941198: In support of mandatory unit files

[Russ Allbery]

Tobias Frost  writes:

> JFTR, I maintain gmedia-resurrect and in this package I failed despite
> trying to create a systemd unit file with equal functinality as the
> init.d script*.  So for this package the proposoal would lead to
> regressions for the users.

A Policy should means that if there is some stronger reason (such as that
adding a unit file would introduce new bugs), there is nothing requiring
you to do so.  It indicates that not having a unit file is a bug, but it's
just a bug, and Debian packages are not expected to be bug-free.  Other
bugs may be more important.

That said, if you'd like help with this, I or someone else following this
thread may be willing to take a look and figure out a way to replicate the
init script behavior.  It's normally possible to handle /etc/default
conffiles in systemd units, although it can be a little complicated.

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

Bug#941198: In support of mandatory unit files

[Tobias Frost]

On Wed, Dec 04, 2019 at 07:03:09PM +0100, Simon Richter wrote:
> Hi,
> 
> chiming in as I've been pointed to this bug: I agree with Ansgar in that
> adding unit files does not hurt sysvinit support in the least, provided we
> still get to ignore them.
> 
> I'd even be in favour of making them mandatory (i.e. upgrading the lintian
> warning to an error), and I don't see how the GR outcome would affect the
> question of whether we want to ship unit files in packages, so I'd be fine
> with going ahead with this change even while the GR is still running.
> 
> As long as we support sysv-rc, init scripts will have to remain mandatory
> as well, though.
> 
> IMO, an ideal outcome would be that systemd can completely ignore any init
> scripts from Debian packages, i.e. the compatibility generator, if
> installed, would only have to generate units for init scripts that didn't
> come from a package, and default installations would not include this
> generator.

JFTR, I maintain gmedia-resurrect and in this package I failed despite trying
to create a systemd unit file with equal functinality as the init.d script*.
So for this package  the proposoal would lead to regressions for the users.
 
> The same should be done for cron files vs timer units -- ideally, we'd get
> to a state where cron files can be completely ignored by systemd because it
> is a bug to not have a timer unit with the same settings. That would allow
> systemd users to get rid of the spurious wakeups as well, which I'd
> consider a major win.
> 
>Simon

* I do not have currently the amount of spoons avialable to explain the details,
but it has to do with the confile in /etc/default needed to be read by the unit
file and parsed into daemon parameters.

Bug#941198: In support of mandatory unit files

[Simon Richter]

Hi,

chiming in as I've been pointed to this bug: I agree with Ansgar in that
adding unit files does not hurt sysvinit support in the least, provided we
still get to ignore them.

I'd even be in favour of making them mandatory (i.e. upgrading the lintian
warning to an error), and I don't see how the GR outcome would affect the
question of whether we want to ship unit files in packages, so I'd be fine
with going ahead with this change even while the GR is still running.

As long as we support sysv-rc, init scripts will have to remain mandatory
as well, though.

IMO, an ideal outcome would be that systemd can completely ignore any init
scripts from Debian packages, i.e. the compatibility generator, if
installed, would only have to generate units for init scripts that didn't
come from a package, and default installations would not include this
generator.

The same should be done for cron files vs timer units -- ideally, we'd get
to a state where cron files can be completely ignored by systemd because it
is a bug to not have a timer unit with the same settings. That would allow
systemd users to get rid of the spurious wakeups as well, which I'd
consider a major win.

   Simon