Re: Is missing SysV-init support a bug?

[Ian Jackson]

Marco d'Itri writes ("Re: Is missing SysV-init support a bug?"):
> On Dec 31, Simon Richter <s...@debian.org> wrote:
> > These are running stretch, and I would like to upgrade them without
> > breaking my existing scripts, which assume sysvinit with runlevels
> > (including one-shot runlevels).
>
> Somebody having legacy scripts which assume sysvinit and that they do 
> not want to change does not make "sysvinit preferred over systemd" as it 
> is being argued.

There is nothing "legacy" about sysvinit, at least if by "legacy" you
mean "is going to go away" or "should be migrated away from" or
something.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Is missing SysV-init support a bug?

[Benda Xu]

Josh Triplett  writes:

> It seems far harder to do so for a service that provides no
> daemonization support at all, expects socket or D-Bus activation,
> integrates with containerization, or otherwise makes use of the
> variety of mechanisms that make it far easier to write more capable
> and secure services these days.

If that is the case, shouldn't the package "Depends:" on systemd?

Benda

Re: Is missing SysV-init support a bug?

[Tollef Fog Heen]

]] Simon Richter 

> A daemon must be capable of running standalone and dealing with the
> fallout of depended-on services shutting down, restarting, crashing or
> being generally unavailable. All of these are significantly harder to
> get right than startup in a SysV environment.

A lot of the time, you can just detect it, exit and leave restarting to
the init system, assuming your init system supports this.  «Don't ever
die» is only the rule if the init system lacks that support.

(Yes, there are cases where you need to handle errors more gracefully,
but having the option of «on error: exit» is useful, especially for
simplistic control loops.)

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

Re: Is missing SysV-init support a bug?

[Simon Richter]

Hi,

On 01.01.2018 17:42, Josh Triplett wrote:

> There's a difference between "dropping support" and "not mandating
> support".

Ideally, yes, but in practice the difference isn't very large. The main
reasons I see for people to use sysvinit are:

 - reliability: there have been a few interesting surprises when systemd
internal functionality changed.

 - standards compliance: you can use a common management framework for
various SysV-compatible systems in a heterogeneous environment.

 - small footprint: starting a few daemons on an embedded system doesn't
require anything more complex than a script to invoke all of them, so
there is no point in keeping a complex program around to resolve
dependencies.

The first two go out of the window if init scripts become optional, and
these are precisely the main reasons for me to run sysvinit.

> It seems far harder to do so for a service that provides no
> daemonization support at all, expects socket or D-Bus activation,
> integrates with containerization, or otherwise makes use of the variety
> of mechanisms that make it far easier to write more capable and secure
> services these days.)

A daemon must be capable of running standalone and dealing with the
fallout of depended-on services shutting down, restarting, crashing or
being generally unavailable. All of these are significantly harder to
get right than startup in a SysV environment.

   Simon



signature.asc
Description: OpenPGP digital signature

Re: Is missing SysV-init support a bug?

[Russ Allbery]

Josh Triplett  writes:

> This thread started with the question of "is it a bug to not have
> sysvinit support". And I think the answer, at this point, is "yes, but
> depending on the level of additional code and maintenance required, it
> might potentially be a wishlist bug". And there's a limit to how much
> maintainers are expected to deal with every wishlist bug, versus passing
> them upstream or seeking volunteers to help.

Yes, I agree with this.  The only additional point that I would add is
that while offering sysvinit support may not provide much according to
objective measures of number of users or technical features, it provides a
*lot* in terms of social cohesion of the project, making fellow developers
feel valued, and continuing to help the project heal from some deep
wounds.

So yes, I agree that it's a wishlist bug, but if people have the time, I
think it's work that's worth doing, assuming it's not ridiculously
complicated for a particular package.

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

Re: Is missing SysV-init support a bug?

[Michael Stone]

On Mon, Jan 01, 2018 at 08:42:52AM -0800, Josh Triplett wrote:

It seems easy
enough to just write a "missing" init script, or accept a patch for one.
It seems far harder to do so for a service that provides no
daemonization support at all, expects socket or D-Bus activation,
integrates with containerization, or otherwise makes use of the variety
of mechanisms that make it far easier to write more capable and secure
services these days.


I think the level of complexity is an important factor as well. For a 
simple "start this daemon" script, it's not a big deal. If the script 
needs to have a bunch of complex logic to support different use cases it 
doesn't make sense at this point to write both a systemd target and an 
init script--the init script isn't going to get much testing, and it's 
likely that there will be more bugs in the complicated logic than 
there'd be for someone who just hard codes their own requirements into 
rc.local (or whatever). As an example think of something like 
openvpn--if the init script didn't already exist, it would be a lot 
easier for someone to just kick off a single openvpn process than to 
make sure that all the logic that sets up multiple processes with 
different configurations was working properly on both systemd & sysvinit 
systems. As the number of sysvinit users continues to decline, I think 
simpler is better to minimize bugs in seldom-used code paths.


Mike Stone

Re: Is missing SysV-init support a bug?

[Josh Triplett]

Russ Allbery wrote:
> Josh Triplett  writes:
> > Russ Allbery wrote:
>
>>> It does, however, mean that it's a good idea for us to continue to
>>> support sysvinit.
>
>> Not quite. It means we should maintain support for sysvinit *scripts*
>> for the foreseeable future; there's no good reason for us to break
>> support for /etc/init.d/* any time soon.
>
> There are other reasons to continue to support sysvinit: developers who
> want to continue to use it, ports that want to continue to use it, and so
> forth.
>
> I don't see any reason to drop support.

There's a difference between "dropping support" and "not mandating
support". I'm entirely in favor of maintaining support for sysvinit for
as long as people continue to be willing to spend their time on it. But
we already, de-facto, let packages decide to not support it and only
support systemd, if nobody cares enough to provide the additional code
and support that would be required to do otherwise. (It seems easy
enough to just write a "missing" init script, or accept a patch for one.
It seems far harder to do so for a service that provides no
daemonization support at all, expects socket or D-Bus activation,
integrates with containerization, or otherwise makes use of the variety
of mechanisms that make it far easier to write more capable and secure
services these days.)

This thread started with the question of "is it a bug to not have
sysvinit support". And I think the answer, at this point, is "yes, but
depending on the level of additional code and maintenance required, it
might potentially be a wishlist bug". And there's a limit to how much
maintainers are expected to deal with every wishlist bug, versus passing
them upstream or seeking volunteers to help.

Re: Is missing SysV-init support a bug?

[Russ Allbery]

Josh Triplett  writes:
> Russ Allbery wrote:

>> It does, however, mean that it's a good idea for us to continue to
>> support sysvinit.

> Not quite. It means we should maintain support for sysvinit *scripts*
> for the foreseeable future; there's no good reason for us to break
> support for /etc/init.d/* any time soon.

There are other reasons to continue to support sysvinit: developers who
want to continue to use it, ports that want to continue to use it, and so
forth.

I don't see any reason to drop support.  It doesn't seem to be hurting
anything, and the dual support model has worked out considerably better
than a lot of people feared it would.

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

Re: Re: Is missing SysV-init support a bug?

[Josh Triplett]

Russ Allbery wrote:
> m...@linux.it (Marco d'Itri) writes:
> > On Dec 31, Simon Richter  wrote:
> 
> >> These are running stretch, and I would like to upgrade them without
> >> breaking my existing scripts, which assume sysvinit with runlevels
> >> (including one-shot runlevels).
> 
> > Somebody having legacy scripts which assume sysvinit and that they do
> > not want to change does not make "sysvinit preferred over systemd" as it
> > is being argued.
> 
> It does, however, mean that it's a good idea for us to continue to support
> sysvinit.

Not quite. It means we should maintain support for sysvinit *scripts*
for the foreseeable future; there's no good reason for us to break
support for /etc/init.d/* any time soon. (It might become necessary to
provide a migration mechanism that helps sysadmins move their legacy
rcS.d scripts, but that shouldn't be particularly hard when nothing in
Debian ships such scripts anymore.)

Re: Is missing SysV-init support a bug?

[Alex Mestiashvili]

On 12/31/2017 07:19 PM, Michael Biebl wrote:
> Am 30.12.2017 um 14:27 schrieb Alex Mestiashvili:
>> On 12/30/2017 01:46 PM, Michael Biebl wrote:
>>> Am 30.12.2017 um 13:02 schrieb Alex Mestiashvili:
>>>
 There are some cases when using sysvinit is preferred over systemd.
 AFAIK there is no way drop some capabilities with systemd geared linux
 containers while it is possible with sysvinit.
>>>
>>> It's the first time I hear about this. Can you please elaborate? I'd
>>> like to know more about this.
>>
>> Last time I run into this issue was more than two years ago. See this
>> link [0]. Quick googling now brought me to this discussion[0]. The issue
>> seem to be fixed now, so I guess I'll give it another try.
> 
> Ok, so this is/was outdated information. Thanks for the confirmation.
> 

Not really. More precisely I don't know what is the status now.
What I have observed a number of times within the last 2 years is that
linux containers with systemd where not working for my needs. The
solution was two switch to sysvinit and forget about the problem.

According to this [0] the issue might be fixed but I have not tested it
so far.

In any case I think it is important to keep sysvinit scripts unless
there is a good reason not to.

[0] https://github.com/lxc/lxc/issues/1737

Re: Is missing SysV-init support a bug?

[Michael Biebl]

Am 30.12.2017 um 14:27 schrieb Alex Mestiashvili:
> On 12/30/2017 01:46 PM, Michael Biebl wrote:
>> Am 30.12.2017 um 13:02 schrieb Alex Mestiashvili:
>>
>>> There are some cases when using sysvinit is preferred over systemd.
>>> AFAIK there is no way drop some capabilities with systemd geared linux
>>> containers while it is possible with sysvinit.
>>
>> It's the first time I hear about this. Can you please elaborate? I'd
>> like to know more about this.
> 
> Last time I run into this issue was more than two years ago. See this
> link [0]. Quick googling now brought me to this discussion[0]. The issue
> seem to be fixed now, so I guess I'll give it another try.

Ok, so this is/was outdated information. Thanks for the confirmation.

-- 
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: Is missing SysV-init support a bug?

[Russ Allbery]

m...@linux.it (Marco d'Itri) writes:
> On Dec 31, Simon Richter  wrote:

>> These are running stretch, and I would like to upgrade them without
>> breaking my existing scripts, which assume sysvinit with runlevels
>> (including one-shot runlevels).

> Somebody having legacy scripts which assume sysvinit and that they do
> not want to change does not make "sysvinit preferred over systemd" as it
> is being argued.

It does, however, mean that it's a good idea for us to continue to support
sysvinit.

We have a workable compromise at the moment, and it doesn't seem to be
causing huge amounts of pain.  As long as that continues, I plan on
continuing to ship init scripts in my packages, although I'm not going to
go to a ton of work to add new and exciting features to them.  (But
patches welcome.)

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

Re: Is missing SysV-init support a bug?

[Marco d'Itri]

On Dec 31, Simon Richter  wrote:

> > There are some cases when using sysvinit is preferred over systemd.
[...]
> These are running stretch, and I would like to upgrade them without
> breaking my existing scripts, which assume sysvinit with runlevels
> (including one-shot runlevels).
Somebody having legacy scripts which assume sysvinit and that they do 
not want to change does not make "sysvinit preferred over systemd" as it 
is being argued.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Is missing SysV-init support a bug?

[Christoph Biedl]

W. Martin Borgert wrote...

> I'm not sure, whether missing SysV support is wishlist, minor,
> or normal. I would accept normal, but some maintainers would
> downgrade severity.

In my understanding of "universal" (Debian, operating system, y'know)
the goal should be to run on as many platforms as reasonably possible.
So unless there's good reason against it - like having other
dependencies on systemd - packages should continue to ship init files.

> The best solution (IMHO) would be dropping SysV support in all
> packages and use systemd-to-sysvinit-converter¹ in case of need.

Given the huge amount of bugs in init scripts[1], this seems like a very
good idea.

> I never tried it myself, however.

Ditto :)  Does it support systemd generators to start with?

Christoph

[1] A while ago I estimated[how?] a quarter of the init scripts around
does not properly check and wait for the daemon termination in the
"stop" action, possibly leading to loss of service as in #802040


signature.asc
Description: Digital signature

Re: Is missing SysV-init support a bug?

[Simon Richter]

Hi,

On 30.12.2017 13:02, Alex Mestiashvili wrote:

>> I would guess that the vast majority of folks still using sysvinit with
>> Debian are running wheezy or older, and thus removing sysvinit scripts
>> from packages in unstable wouldn't affect them. But maybe that still
>> leaves a reasonable number of testing/unstable + sysvinit users.
> There are some cases when using sysvinit is preferred over systemd.

Indeed. Most of my machines run sysvinit, except for a few throwaway VMs
that don't need to be integrated into my management scripts anyway
because they are rebuilt on each reboot.

These are running stretch, and I would like to upgrade them without
breaking my existing scripts, which assume sysvinit with runlevels
(including one-shot runlevels).

   Simon



signature.asc
Description: OpenPGP digital signature

Re: Is missing SysV-init support a bug?

[Paul Wise]

On Sun, Dec 31, 2017 at 12:54 PM, Steve Langasek wrote:

> And in what context would you find yourself trying to run a Debian init
> system in such an environment?

Often mainline Linux doesn't support particular embedded/mobile
systems (especially ARM/MIPS) or has a bug that isn't present in the
vendor version of Linux.

Here is an example from debian-arm recently where Debian userspace
requirements blocked part of an investigation of a mainline Linux
kernel bug:

https://lists.debian.org/debian-arm/2017/12/msg00013.html

Pretty much any ARM mobile device that ships with Android only has the
possibility of running Debian in a chroot.

https://wiki.debian.org/ChrootOnAndroid

Another example is one of my ADSL modems, which can run a Debian
userspace in a chroot under the vendor version of Linux but is never
going to run Linux mainline. In addition, Debian bumped the MIPS
baseline for some reason so it can't run anything later than Debian
jessie anyway.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Is missing SysV-init support a bug?

[Steve Langasek]

On Sat, Dec 30, 2017 at 01:38:10PM +0100, W. Martin Borgert wrote:
> On 2017-12-30 13:02, Alex Mestiashvili wrote:
> > There are some cases when using sysvinit is preferred over systemd.
> > AFAIK there is no way drop some capabilities with systemd geared linux
> > containers while it is possible with sysvinit.

> Unfortunately, on some embedded and/or mobile systems, one has
> to stick to an old Linux kernel, even when using the latest user
> space. Systemd needs at least Linux 3.13.

And in what context would you find yourself trying to run a Debian init
system in such an environment?  oldstable has a 3.16 kernel; oldoldstable
has 3.2, but that means it will be oldoldoldstable when buster is released. 
Do you actually expect any guarantees that the buster userspace will be
compatible with a kernel of release-3 vintage?

If so, I think you have an uphill battle to codify such an expectation in
the release-critical bug guidelines.

If not, I think you will find other userspace incompatibilities creeping in.
In particular, I expect glibc's minimum kernel compatibility level to
continue to ratchet up.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Is missing SysV-init support a bug?

[Marco d'Itri]

On Dec 30, Alex Mestiashvili  wrote:

> AFAIK there is no way drop some capabilities with systemd geared linux
> containers while it is possible with sysvinit.
Here it is: no CAP_SYS_ADMIN.

# cat /etc/systemd/nspawn/secure.nspawn 
[Exec]
DropCapability=CAP_AUDIT_CONTROL CAP_MKNOD CAP_NET_RAW CAP_SYS_MODULE 
CAP_SYS_RAWIO CAP_SYS_TIME CAP_SYSLOG CAP_WAKE_ALARM CAP_SYS_ADMIN

[Files]
TemporaryFileSystem=/run/lock


-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Is missing SysV-init support a bug?

[Alex Mestiashvili]

On 12/30/2017 01:46 PM, Michael Biebl wrote:
> Am 30.12.2017 um 13:02 schrieb Alex Mestiashvili:
> 
>> There are some cases when using sysvinit is preferred over systemd.
>> AFAIK there is no way drop some capabilities with systemd geared linux
>> containers while it is possible with sysvinit.
> 
> It's the first time I hear about this. Can you please elaborate? I'd
> like to know more about this.
> 
> 
> 

Last time I run into this issue was more than two years ago. See this
link [0]. Quick googling now brought me to this discussion[0]. The issue
seem to be fixed now, so I guess I'll give it another try. But
nevertheless a container template with sysvinit works just fine for me.

[0] https://github.com/debops/ansible-lxc/issues/15
[1] https://github.com/lxc/lxc/issues/1737

Re: Is missing SysV-init support a bug?

[Michael Biebl]

Am 30.12.2017 um 13:02 schrieb Alex Mestiashvili:

> There are some cases when using sysvinit is preferred over systemd.
> AFAIK there is no way drop some capabilities with systemd geared linux
> containers while it is possible with sysvinit.

It's the first time I hear about this. Can you please elaborate? I'd
like to know more about this.





signature.asc
Description: OpenPGP digital signature

Re: Is missing SysV-init support a bug?

[W. Martin Borgert]

On 2017-12-30 13:02, Alex Mestiashvili wrote:
> There are some cases when using sysvinit is preferred over systemd.
> AFAIK there is no way drop some capabilities with systemd geared linux
> containers while it is possible with sysvinit.

Unfortunately, on some embedded and/or mobile systems, one has
to stick to an old Linux kernel, even when using the latest user
space. Systemd needs at least Linux 3.13.

I'm not sure, whether missing SysV support is wishlist, minor,
or normal. I would accept normal, but some maintainers would
downgrade severity.

The best solution (IMHO) would be dropping SysV support in all
packages and use systemd-to-sysvinit-converter¹ in case of need.
I never tried it myself, however.

¹https://github.com/akhilvij/systemd-to-sysvinit-converter

Re: Is missing SysV-init support a bug?

[Alex Mestiashvili]

On 08/26/2016 01:47 AM, Robert Edmonds wrote:
> Russ Allbery wrote:
>> Robert Edmonds  writes:
>>
>>> However, that was two years ago. How long should we be expected to
>>> continue maintaining sysvinit scripts?
>>
>> My understanding of the feeling of the TC at the time is that maintainers
>> are expected to continue including the sysvinit scripts for as long as (a
>> reasonable number of) folks are using sysvinit with Debian and keeping it
>> working, a bar that I think is still being easily met.
> 
> I would guess that the vast majority of folks still using sysvinit with
> Debian are running wheezy or older, and thus removing sysvinit scripts
> from packages in unstable wouldn't affect them. But maybe that still
> leaves a reasonable number of testing/unstable + sysvinit users.
> 

There are some cases when using sysvinit is preferred over systemd.
AFAIK there is no way drop some capabilities with systemd geared linux
containers while it is possible with sysvinit.

Re: Is missing SysV-init support a bug?

[Ian Jackson]

Steve Langasek writes ("Re: Is missing SysV-init support a bug?"):
> On Tue, Oct 18, 2016 at 08:11:21PM -0700, Russ Allbery wrote:
> > The reactions of others is not about the spelling difference, which is
> > obviously trivial.  It's about the refusal to change, the insistence on
> > mislabeling something, and the surprising anger and oddly twisted defenses
> > that ensue afterwards, making it clear that this is a marker of something
> > much deeper and much darker than just a trivial mistake.
> 
> So... a shibboleth. ;)

Maybe the list software could be configured to use this helpful marker
inexplicably placed on useless and inflammatory messages by their very
authors.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Is missing SysV-init support a bug?

[Steve Langasek]

On Tue, Oct 18, 2016 at 08:11:21PM -0700, Russ Allbery wrote:
> You will find that when you point out the correct spelling to those who
> use this one, the response is not "oh, whoops," like it would be for a
> mistake.  Rather, it's usually a rant of surprising vitriol, a bunch of
> bizarrely constructed justifications for why their spelling is correct,
> and an insistence on continuing to use it.  You can see that happen on
> this very thread.

> That means "mistake" is clearly not the correct term.

> I find the correct term a bit mysterious, partly because I don't
> understand the impulse, but I suspect it's much closer to "dog-whistle"
> [1] or "tribal marker" than "mistake."

> The reactions of others is not about the spelling difference, which is
> obviously trivial.  It's about the refusal to change, the insistence on
> mislabeling something, and the surprising anger and oddly twisted defenses
> that ensue afterwards, making it clear that this is a marker of something
> much deeper and much darker than just a trivial mistake.

So... a shibboleth. ;)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Is missing SysV-init support a bug?

[Russ Allbery]

Cameron Norman  writes:

> Those reading so much into such a small and understandable
> capitalization mistake (SystemV -> SystemD) should learn to take
> themselves less seriously and view things from different perspectives.

You will find that when you point out the correct spelling to those who
use this one, the response is not "oh, whoops," like it would be for a
mistake.  Rather, it's usually a rant of surprising vitriol, a bunch of
bizarrely constructed justifications for why their spelling is correct,
and an insistence on continuing to use it.  You can see that happen on
this very thread.

That means "mistake" is clearly not the correct term.

I find the correct term a bit mysterious, partly because I don't
understand the impulse, but I suspect it's much closer to "dog-whistle"
[1] or "tribal marker" than "mistake."

The reactions of others is not about the spelling difference, which is
obviously trivial.  It's about the refusal to change, the insistence on
mislabeling something, and the surprising anger and oddly twisted defenses
that ensue afterwards, making it clear that this is a marker of something
much deeper and much darker than just a trivial mistake.

[1] https://en.wikipedia.org/wiki/Dog-whistle_politics for those
unfamiliar with this term.

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

Re: Is missing SysV-init support a bug?

[Nikolaus Rath]

On Oct 18 2016, Cameron Norman  wrote:
> On Tue, Oct 18, 2016 at 11:23 AM, Lars Wirzenius  wrote:
>> On Tue, Oct 18, 2016 at 07:34:28PM +0200, Xen wrote:
>>> If that is the case then they have enbedded hostility into their name simply
>>> becaus eit offends normal grammar roles.
>>
>> I don't that's it at all.
>>
>> The reason many people react to the SystemD spelling is becuase, for
>> some years now, trolls use that spelling when harrassing others about
>> systemd.
>>
>> Calling it SystemD indicates to many people that you're the kind of
>> person show turns up from nowhere, and starts spreading fear,
>> uncertainty, and doubt about systemd, or presenting conspiracy
>> theories about it, or making ad hominem attacks on its authors. People
>> with bad experiences from previous systemd discussions will assume
>> you're that kind of troll, regardless of the value of any of your
>> claims or statements may have. Or at least I do.
>
> Those reading so much into such a small and understandable
> capitalization mistake (SystemV -> SystemD)

It doesn't matter if the difference is small or big. What matters is
that in the past this difference has been an excellent predictor of
everything else the author has to say. It's rare that one can draw so
much information out of so little data, so I don't think its reasonable
to expect people to stop relying on it.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Is missing SysV-init support a bug?

[Cameron Norman]

On Tue, Oct 18, 2016 at 11:23 AM, Lars Wirzenius  wrote:
> On Tue, Oct 18, 2016 at 07:34:28PM +0200, Xen wrote:
>> If that is the case then they have enbedded hostility into their name simply
>> becaus eit offends normal grammar roles.
>
> I don't that's it at all.
>
> The reason many people react to the SystemD spelling is becuase, for
> some years now, trolls use that spelling when harrassing others about
> systemd.
>
> Calling it SystemD indicates to many people that you're the kind of
> person show turns up from nowhere, and starts spreading fear,
> uncertainty, and doubt about systemd, or presenting conspiracy
> theories about it, or making ad hominem attacks on its authors. People
> with bad experiences from previous systemd discussions will assume
> you're that kind of troll, regardless of the value of any of your
> claims or statements may have. Or at least I do.

Those reading so much into such a small and understandable
capitalization mistake (SystemV -> SystemD) should learn to take
themselves less seriously and view things from different perspectives.

Re: Is missing SysV-init support a bug?

[Lars Wirzenius]

On Tue, Oct 18, 2016 at 07:34:28PM +0200, Xen wrote:
> If that is the case then they have enbedded hostility into their name simply
> becaus eit offends normal grammar roles.

I don't that's it at all.

The reason many people react to the SystemD spelling is becuase, for
some years now, trolls use that spelling when harrassing others about
systemd.

Calling it SystemD indicates to many people that you're the kind of
person show turns up from nowhere, and starts spreading fear,
uncertainty, and doubt about systemd, or presenting conspiracy
theories about it, or making ad hominem attacks on its authors. People
with bad experiences from previous systemd discussions will assume
you're that kind of troll, regardless of the value of any of your
claims or statements may have. Or at least I do.

We've had systemd related discussions for years. Just about every real
or imaginable problem with systemd has been raised. Even so, we chose
it as the default init in Debian, while keeping support for other
inits, and those railing against this are just not worth arguing with
anymore.

Those who report actionable issues in systemd, or in our support for
other init systems, are welcome and should get all due attention. Bugs
are bugs and bugs should be squashed.

Everything in this mail is my personal opinion. It's possible other
members of the community working on Debian have different opinions.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Is missing SysV-init support a bug?

[Xen]

Not subscribed so this will break threading.


On 2016-10-17 at 17:53, Bart Schouten wrote:



I would consider that bigotry as SystemD is short pretty much for
System Daemon.



While this is a reasonable point, it doesn't invalidate Nikolas' point:
that the people behind the systemd project A: do not consider it to be
spelled that way (and, yes, capitalization is part of correct spelling,
at least when it comes to names), B: are likely to perceive the refusal
to spell it in the way which they see as correct to be a sign of
hostility, and C: are likely to react accordingly to that perceived
hostility.


If that is the case then they have enbedded hostility into their name 
simply becaus eit offends normal grammar roles.


If ou are ygoing to name your son "john" and then insist that everyone 
write your name in lowercase, you are going to have issues.


*every software out there is going to capitazlize the first letter
*people all over will refuse to write it with a lowercase only.

*proper names (proper nouns) are written by default in our languages 
with an upeer case initial latter. This breaks grammaticasl rules and 
idiomatic rules.


I mean, what is the intent here? To stir up trouble reagrdless?

You can claim that I am the deviant here, but that is not so. These 
authors apparently willingly disrupt natural language flow in a language 
that has upper case and lower case letters. What about German? Even 
regular nouns are capitalized and you want to write it with lowercase.


Apparently Lennart Poettering himself wants the name to be lowercased 
(he wrote the section on the webpage himself, he told me) (that 
references the spellin0 but with all due respect, your language skills 
completely suck if youinsist on writing it lowercased even when writing 
text athat is supposed to be flowing prose.


It's really cute if you can use monomspaced font in your text when all 
the rest is sans-serif, you know, so it doesn't trouble you so much, but 
these are emails.


We have no markup here, it is all monospace, or whatever you ahve.

I mean Lennart is a nice guy when you respond nicely to him and it is 
pretty nice to talk to him but this is not about him, he doesn't need to 
write the words that I use, nor are you by definition "his people", itś 
as if we are now no longer allowed *anywhere* to write it the way we 
want, another dictatorship? If it concerns him (or his team, fine). 
Whyshould it concern me the rest of the time?


I should suffer unreadable text because Lennart or someone else has a 
pecularity about it? I rather doubt he is a guy like that, you know, 
that we would care what other epople do at the other side of the 
universie, to him.


But more importantly it makes me question the validity of the Debian 
project if it identifies with SystemD so much that IT becomes hostile 
when the name of its components (or one of its components, I was meaning 
to write) is written in the "wrong" way. That means you are no longer 
independent people and that's what worries me.



Without taking sides on the question at hand: do you, then, spell the
name of the distribution as DebIan?


Is that the most reasonable capitalisation of that name?

I didn't even know what it stood for, I must say.

But you know full well that people would tire of writing DebIan within a 
minute, and coincidentally, Debian is the propr form of a proper noun in 
our language. Most words that are written as ca combination of two tend 
to become a single noun: Facebook, Wikipedia, it is way too annoying to 
write it with two capitals. Midway, at least.


But Systemd is not a word, and System is a word, and it stands to reason 
that you would write either systemd or SystemD. Nothing else makes 
sense. So then if you need to use capitals to make the text stand out 
more you use SystemD just like SystemV (or System V) used to be writen. 
This stands to reason. *I* can't help it that the name conflicts with 
and offends natural language as we write it. *I* can't hep it that the 
name interferes with normal grammatical rules. I did not choose the 
name, why should I suffer for it?


And I think it is just pretty change if you would go so far as to make 
this a point of contention which makes me feel you have other issues.


Mister the Wanderer, maybe your signature is meaningful here ;-). Or at 
least, reasonable ;-0).


By the way, again people manage to make a mountain out of a molehill 
which means to me they really have nothing better to do than this and it 
maens to me they are wasting their time on what they *are* doing.

Re: Is missing SysV-init support a bug?

[The Wanderer]

On 2016-10-17 at 17:53, Bart Schouten wrote:

> Nikolaus Rath schreef op 17-10-2016 18:26:
> 
>> On Oct 17 2016, Bart Schouten  wrote:
>> 
>>> (And I write SystemD with caps because that makes it easier to
>>> read, people invented capitals for a reason).
>> 
>> What would you think some people consistently spelled your name as
>> Bart SchouteN with the same justification?
> 
> I would consider that bigotry as SystemD is short pretty much for
> System Daemon.

While this is a reasonable point, it doesn't invalidate Nikolas' point:
that the people behind the systemd project A: do not consider it to be
spelled that way (and, yes, capitalization is part of correct spelling,
at least when it comes to names), B: are likely to perceive the refusal
to spell it in the way which they see as correct to be a sign of
hostility, and C: are likely to react accordingly to that perceived
hostility.

>> And if that set of people also happened to coincide exactly with
>> your most vocal critics?
>> 
>> How you write your emails is up to you, but you're not making it
>> likely for them to be well received.
> 
> Because I write the name of a project in the most reasonable
> capitalized form.

Without taking sides on the question at hand: do you, then, spell the
name of the distribution as DebIan?

-- 
   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: lamenting current developments [was: Re: Is missing SysV-init support a bug?]

[Bart Schouten]

Adam D. Barratt schreef op 17-10-2016 17:38:

On 2016-10-17 16:04, Bart Schouten wrote:

I also want to just quickly summarize my position here, since some
very long posts were written on this and linked into the thread by
someone.


And you then wrote another very long post. We really don't need another 
one.


Well, I'm glad you're never hostile to anyone else either, Adam.

I did not say those posts were written here (they were blog posts linked 
in and people were urged to read it) and I do also not intend to start 
debating, I was just cleaning up old email and I ran across this, and 
just felt I needed to finish that. Alright?


I am also unsubscribing because the bug reports (are they part of 
debian-devel?) are too much of a distraction.


It is also pretty remarkable that by their own actions the ones who want 
to stifle a debate or cut short a chain of messages often act in such a 
way as to further a new chain of messages to arrive, or arise. By their 
rudeness and hostility they often prompt more responses when that was 
never the intent of the original poster. Bug reports made out of a bug 
report system fall into that category, where they give rise to heated 
debate when such was never the intent of the reporter; he or she merely 
wanted to pass something along. A report of something that's not working 
is then met by hostile responses that question everything that has been 
said, when the intent was clearly to provide support, not defamation. 
Maybe you should stop thinking the entire world is against you, you 
know.


You could also respond with "Well thank you for your opinion, I hope it 
is closed that way for now."


Or anything of the kind. But no, you choose hostility.

In any case, regards, and cya<-- go ahead and prove me right, right 
now.


*Shakes head*.

Re: Is missing SysV-init support a bug?

[Bart Schouten]

Nikolaus Rath schreef op 17-10-2016 18:26:

On Oct 17 2016, Bart Schouten  wrote:

(And I write SystemD with caps because that makes it
easier to read, people invented capitals for a reason).


What would you think some people consistently spelled your name as Bart
SchouteN with the same justification?


I would consider that bigotry as SystemD is short pretty much for System 
Daemon.


Also, I do not consider or remember that you are systemd employees.

I am glad you are spending your time on things that are important 
though.




And if that set of people also happened to coincide exactly with your
most vocal critics?

How you write your emails is up to you, but you're not making it likely
for them to be well received.


Because I write the name of a project in the most reasonable capitalized 
form.


You really have your priorities right, sir.



Best,
-Nikolaus

Re: Is missing SysV-init support a bug?

[Nikolaus Rath]

On Oct 17 2016, Bart Schouten  wrote:
> (And I write SystemD with caps because that makes it
> easier to read, people invented capitals for a reason).

What would you think some people consistently spelled your name as Bart
SchouteN with the same justification?

And if that set of people also happened to coincide exactly with your
most vocal critics?

How you write your emails is up to you, but you're not making it likely
for them to be well received.

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: lamenting current developments [was: Re: Is missing SysV-init support a bug?]

[Adam D. Barratt]

On 2016-10-17 16:04, Bart Schouten wrote:

I also want to just quickly summarize my position here, since some
very long posts were written on this and linked into the thread by
someone.


And you then wrote another very long post. We really don't need another 
one.


Regards,

Adam

lamenting current developments [was: Re: Is missing SysV-init support a bug?]

[Bart Schouten]

I also want to just quickly summarize my position here, since some very 
long posts were written on this and linked into the thread by someone.


I have only three issues with SystemD in order of diminishing 
importance:


1) it is very hard to get up to speed with systemd, you run up against 
walls where you don't know how to proceed
2) the lack of flexibility mentioned by Russ and Simon. It is very hard 
to schedule something for shutdown alone, for instance.
3) the bad command environment; journalctl, systemctl, all of the -ctl 
names are hard to use. It is not user friendly, you get confused, you 
type the wrong things; apt (and its verbs) is like the opposite of that; 
easy, fast, quick to learn, quick to remember.


For me all of that points to a bad design and I haven't read the 
criticism that was also linked in this thread (by Jonathan de Boyne 
Pollard, on 01-09 (september)).


Personally I would not have made the choice to go with SystemD (site 
wide, so to speak) because I think SysV init can be improved and I 
disagree with the notion that it could not be used as the basis for 
something that would provide more standardized services, but of course I 
never went there as a person. Precisely because it is based on scripts 
(while also having descriptive elements) it can be evolved into 
something into something that does a better job than it does now until 
it would get to the point where you started replacing scripts with 
something more solid after you got the model for that right, but of 
course I never did any of that.


The main issue I have with it personally is that once you have a higher 
level functionality built on a bad model it will be impossible to change 
it. As long as you stick to the lesser-high level functionality based on 
a good model, you are still free to go in whatever you like.


The SystemD integration has cut off development paths and trackts and 
makes it virtually impossible to go back after the fact and take another 
path still. It's a consolidation but it means the interest for an 
alternative path will become less and less while all the while having a 
system built on a very bad model with deep issues relating to the many 
failure cases SystemD can have and that I witness quite often.


Just today someone ran into the problem of trying to mount some local 
filesystems on top of NFS but it couldn't be done because SystemD orders 
remote mounts after local mounts. The unaware person will not have a 
single clue as to why it is not working. There are more directives that 
get conveniently broken by SystemD when it messes or interferes with its 
ordering mechanics. People continually run into things that do not work 
as expected and this "breach of contract" is the biggest issue.


Most of the time you will simply not know how to do something until you 
ask the developers or someone with experience.


And then they will mention caveat #2311. But it was impossible to know 
beforehand and that turns it into an oblique system. And troubleshooting 
boot failures is rather expensive...


So for me personally it is a very independable system with a high risk 
of breaking the moment you change something, anything, whteher it is 
custom encryption, or some mount, or anything else. Shutdown can take 
very long for reasons you don't know and have almost no way to 
troubleshoot.  And this is just my personal impression, my personal 
experience that I have to deal with, nothing else.


Just stating what it is for me without any comparison to any other 
system. I mean the things I run into with Systemd.


These things stand on their own and are just true, for me, they have 
happened, all of them. That's all, I just think I am worse off because a 
/bad/ high level feature had closed off development paths to 
alternatives since pretty much no one is going to be interested in it, 
or that there would be developers interested in it, nor that it becomes 
easier to run these systems, and have them available for yourself to 
work with.


So if I am at any time vehemently arguing for the non-throwing-away of 
some script, it is also because I see opportunities for myself grow 
dimmer by the minute... That's all. And I can't fight that because I'm 
not "there" and I am not in that position to actually do something with 
it.


But the chances of /getting/ to that position become worse. So 
personally, for me, not only as a user, but also as a developer, I see 
conditions worsen. I like SysV-init better because it has more 
potential, you can do more with it, you can go directions with it. It is 
an open-ended story, but SystemD is not.


I can't take SystemD and turn it into something else. That's practically 
impossible. I could have taken SysV and turned it into something else, 
easily. I wasn't there yet, but I could have gotten there in time.


But the chances of that ever taking place (within reasonable time) are 
now probably 20% of what they were before. I like systems in their early 

Re: Is missing SysV-init support a bug?

[Bart Schouten]

I just want to respond after all this time because I ignored this debate 
as I hadn't had time for it.


Russ you state in the email of 30-08 that you wish people would realize 
the nuances between a system that can do one thing and a system that can 
do another thing and both have advantages, and Simon Richter stated the 
same and wrote a long blog post that I've also read.


When I voiced my problem with the idea that SystemD would be by 
definition superior, it was along the same idea.


I have no issue whatsoever with claiming that SystemD is better at some 
things. (And I write SystemD with caps because that makes it easier to 
read, people invented capitals for a reason). I only had an issue with 
unequivocally claiming that SystemD would be better at "everything" and 
hence be the "superior" project.


I like to say that superiority is something you can only claim based on 
a goal; the goal is a subjective thing, once you have the subjective 
thing (the goal) you can make objective assessments with regards to that 
goal. But you cannot make universal statements as to the superiority of 
anything.


A broken pot is superior at watering the ground. It may not be superior 
for holding and watering the plants held within it, but surely it will 
do a better job at spilling water on the ground.


That's why I wrote, as has been responded to, "But that's not the 
relevance. The idea that systemd is clearly superior to sysvinit is just 
something you concoct up because you don't know how to write a service 
file or script and you want to let systemd do the hard work.", and for 
no other reason really.


I mean, Mac lovers love Apple, and apple provides very high level 
functionality that has very low flexibility. If its model is not 
suitable to you, you cannot use the software. At the same time these 
people might claim "What's your problem? It's just easier!".


I never claimed SysV was superior. I just had a problem with the 
unequivocal "superiority" of SystemD being used as a brandishing stick 
to burn SysV scripts with. So Nikolaus Rath's response that:


"How is that concoted? Yes, systemd is clearly superior to sysvinit
because it doesn't require me to know how to write a service file or
script but does the hard work for me." -- was unwarranted.

I was not arguing for the superiority of SysV. I was arguing against the 
superiority of SystemD. I was basically arguing against superiority, not 
for it.


I just thought that the reasons for saying that "SystemV-init was 
outdated, and we're in 2016 now, and any sensible developer will know 
that SystemD is superior" -- and all of that --- were populist in nature 
and not rational; as if we have a Robber's Cave experiment where we have 
to prove which is the best team -- but there can only be one winner.

Subjects and threads (was: Re: Is missing SysV-init support a bug?)

[Adam D. Barratt]

On Sat, 2016-09-03 at 21:01 +0100, Jonathan de Boyne Pollard wrote:

[stuff]

btw, I'm sure I'm not the only one irritated by this, but when replying
to a message it is conventional to indicate such in the Subject header
(e.g. with the addition of an "Re:"), unless one is changing the subject
- and even then, stating the previous subject as well is useful.

Regards,

Adam

Re: Is missing SysV-init support a bug?

[Jakub Wilk]

* Adam Borowski , 2016-09-03, 22:40:

* https://jdebp.eu./Softwares/nosh/debian-binary-packages.html#run


I'm afraid your page is not working, on any of: Firefox, Chromium, Edge:
there's both a certificate name mismatch, then wrongly configured SNI.

Of course, dropping the stray dot helps, but as you insist on using it 
you need to configure your server appropriately.  I'm not sure you can 
get a cert with the dot signed by a CA, though.


elinks does accept it, but I'm afraid that limits your audience rather 
sharply.


And that's because certificate verification in elinks is broken:
https://bugs.debian.org/740981

--
Jakub Wilk

Re: Is missing SysV-init support a bug?

[Adam Borowski]

On Sat, Sep 03, 2016 at 01:11:52PM +0100, Jonathan de Boyne Pollard wrote:
> * https://jdebp.eu./Softwares/nosh/debian-binary-packages.html#run

I'm afraid your page is not working, on any of: Firefox, Chromium, Edge:
there's both a certificate name mismatch, then wrongly configured SNI.

Of course, dropping the stray dot helps, but as you insist on using it you
need to configure your server appropriately.  I'm not sure you can get a
cert with the dot signed by a CA, though.

elinks does accept it, but I'm afraid that limits your audience rather
sharply.


Meow!
-- 
Second "wet cat laying down on a powered-on box-less SoC on the desk" close
shave in a week.  Protect your ARMs, folks!

Is missing SysV-init support a bug?

[Jonathan de Boyne Pollard]

Gerrit Pape:

To me too this readiness IPC ideas and implementations look 
over-engineered.


A good convention for service programs would be to functionally test 
for services it needs very early on startup, and fail if dependencies 
are not available. The service supervisor (any modern init scheme 
seems to now support this) relaunches eventually, until all 
dependencies are fulfilled.


The problem with the thundering herd approach is twofold. Firstly, it 
really does matter in practice when the machine has tens if not hundreds 
of client processes all continually restarting whilst they wait for 
(say) the RabbitMQ server to come up.  Secondly, these explanations 
never seem to take system shutdown into account.  In the ordered 
services world, shutdown order is the reverse of startup order, and 
things generally work. In the thundering herd world, often the theory is 
just to send terminate and kill signals willy-nilly to every service on 
the system.  This almost never works cleanly in any but the most trivial 
systems.  (People will no doubt be thinking the classic example of NFS 
mounts, here.  But there are all sorts of possibilities, from /var/ 
being unmounted before logging services are turned off to the proxy DNS 
server being turned off whilst other services are still doing DNS lookups.)


We discussed this on the Supervision mailing list last year: 
http://www.mail-archive.com/supervision%40list.skarnet.org/msg00673.html

Is missing SysV-init support a bug?

[Jonathan de Boyne Pollard]

Gerrit Pape:

My suggestion was and still is to separate services from programs on 
the package level, [...]


I vaguely remember from the systemd packaging Hoo-Hah someone else 
advocating this idea.  I don't recall who it was off the top of my head.


Gerrit Pape:


I was not successful to convince fellows back then.


I wouldn't say that.

* https://jdebp.eu./Softwares/nosh/debian-binary-packages.html#run

And there's the division between systemd and systemd-sysv, too.

Re: Is missing SysV-init support a bug?

[Tollef Fog Heen]

]] Gerrit Pape 

> A good convention for service programs would be to functionally test for
> services it needs very early on startup, and fail if dependencies are
> not available.  The service supervisor (any modern init scheme seems to
> now support this) relaunches eventually, until all dependencies are
> fulfilled.  Consequently, if while running one of the needed services
> fails for some reason, fail also.  Supervisors are going to bring things
> up again.  That's how runit does things.
> 
> If the initialization of some (bloat) service program really is that
> expensive before it can functionally check for dependencies, it could
> implement the wait-and-retry on its own.

I don't think it's a good idea for random daemons to implement support
for «wait until a particular file system in fstab is mounted», which
seems to be what you're advocating for.

Also, having this support in every single daemon means the local admin
is at the mercy of various upstreams to implement this support (of which
some portion are going to go «I don't want to implement that»), rather
than having it implemented once, correctly, in the init system.

The waste of CPU cycles is the least of the problems dependencies try to
fix.  Incorrect operation is a much more interesting one.

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

Re: Is missing SysV-init support a bug?

[Samuel Thibault]

Adam Borowski, on Fri 02 Sep 2016 05:30:10 +0200, wrote:
> Let's see, printf 'a\e[3mb\e[0mc\n' (b should be italic, a and c should not)

Err, here:

* aterm: -
* Eterm: -
* gnome-terminal: +
* konsole: +
* lxterm: +
* lxterminal: -
* mlterm: +
* pterm: -
* roxterm: +
* rxvt-unicode: +
* screen: translate to inverse video
* xfce4-terminal: -
* xterm: +

are you perhaps just not using a font which can do italic ?

Samuel

Re: Is missing SysV-init support a bug?

[gregor herrmann]

On Fri, 02 Sep 2016 05:30:10 +0200, Adam Borowski wrote:

> Let's see, printf 'a\e[3mb\e[0mc\n' (b should be italic, a and c should not)

> * rxvt-unicode: -

FWIW, works for me (rxvt-unicode-256color).
Might be a font (configuration) issue, the 'b' looks interesting
here.

Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Tom Waits: Barcarolle


signature.asc
Description: Digital Signature

Re: Is missing SysV-init support a bug?

[Stephen Kitt]

On Fri, 2 Sep 2016 05:30:10 +0200, Adam Borowski  wrote:
> What "wide range of terminals that /can/ /do/ /italics/" do you mean?
> 
> Let's see, printf 'a\e[3mb\e[0mc\n' (b should be italic, a and c should not)
> * linux console:- (text does nothing, fb makes it green)
> * xfce4-terminal:   -
> * lxterminal:   -
> * xterm:✓
> * rxvt-unicode: -
> * pterm -
> * cool-retro-term:  -
> And out of Debian:
> * osso-xterm:   -
> * putty:-
> * win10 console:-
> * Solaris console:  -
> * OpenBSD console:  - (text)

FWIW, GNOME Terminal also supports italics.

Regards,

Stephen


pgprG2KYR0Rgf.pgp
Description: OpenPGP digital signature

Re: Is missing SysV-init support a bug?

[Adam Borowski]

On Thu, Sep 01, 2016 at 10:09:42AM +0100, Jonathan de Boyne Pollard wrote:
> Like fulfilling the 1970s Unix promise of italics in manual pages, on the
> wide range of terminals that /can/ /do/ /italics/: stymied on Debian and
> only documented by a note at the bottom of a closed and forgotten bug report
> filed roughly a decade and a half ago against a long since superseded
> version.  A couple of Hitch-Hiker's Guide to the Galaxy quotations come to
> mind.
> 
> * https://jdebp.eu./Softwares/nosh/italics-in-manuals.html

What "wide range of terminals that /can/ /do/ /italics/" do you mean?

Let's see, printf 'a\e[3mb\e[0mc\n' (b should be italic, a and c should not)
* linux console:- (text does nothing, fb makes it green)
* xfce4-terminal:   -
* lxterminal:   -
* xterm:✓
* rxvt-unicode: -
* pterm -
* cool-retro-term:  -
And out of Debian:
* osso-xterm:   -
* putty:-
* win10 console:-
* Solaris console:  -
* OpenBSD console:  - (text)

Hmm... 1 out of 11¹ implementing italics plus one doing some other thing
doesn't strike me as a "wide" range.

I didn't bother to test terminals I don't have installed at the moment but
the above sample shouldn't be much off.


[1]. Not counting putty=pterm twice.
-- 
Second "wet cat laying down on a powered on box-less SoC on the desk" close
shave in a week.  Protect your ARMs, folks!

Re: Is missing SysV-init support a bug?

[Gerrit Pape]

On Mon, Aug 29, 2016 at 09:47:53PM +0200, Simon Richter wrote:
> On 28.08.2016 22:11, Bart Schouten wrote:
> > That "very serious race condition" is nothing more than one daemon
> > having to wait for the other while starting up. THAT'S IT. Oh and
> > knowing when something has died so you can restart it or something.
> 
> That is also something the init system can not really fix, just paper over.
> 
> Any daemon that is dependent on another to work needs to be able to
> handle the case where the other process is restarted, or fails for some
> reason, and provide error recovery in this case. Declaring a dependency
> in a systemd unit file is no better in that regard than simply ordering
> daemons by priority, and ideally the daemon needs to be resilient enough
> to work even if the other daemon is started with no synchronisation or
> if timed jobs are simply not run.
> 
> I'd also postulate that these error cases are not properly tested in
> most daemons we have. Every service can always fail due to transient
> errors, and this needs to be communicated up the stack. There is a
> reason why SMTP daemons will first write a mail to disk, flush the
> caches, and only then acknowledge receipt.

To me too this readiness IPC ideas and implementations look
over-engineered.

A good convention for service programs would be to functionally test for
services it needs very early on startup, and fail if dependencies are
not available.  The service supervisor (any modern init scheme seems to
now support this) relaunches eventually, until all dependencies are
fulfilled.  Consequently, if while running one of the needed services
fails for some reason, fail also.  Supervisors are going to bring things
up again.  That's how runit does things.

If the initialization of some (bloat) service program really is that
expensive before it can functionally check for dependencies, it could
implement the wait-and-retry on its own.

Good thing is that this convention applies to the service program that
actually is causing the issue (multiple, expensive startups) and can be
fixed there, while readiness IPC requires the dependencies to "fix"
things.

Regards, Gerrit.

Re: Is missing SysV-init support a bug?

[Gerrit Pape]

On Fri, Aug 26, 2016 at 12:11:13AM +0200, Sven Hartge wrote:
> I just saw the new conntrack-tools (1:1.4.4-2) package in Sid, which
> has as a change
> 
>   * [917beed] conntrackd: get rid of the sysvinit support
> 
> and I wondered, if this is a bug (and at what severity) or not.

Hi, something similar was discussed in history already, and appears to
be an issue whenever more than one init scheme comes into play, not
releated to systemd specifically

 https://bugs.debian.org/422139#86

My suggestion was and still is to separate services from programs on the
package level, see

 https://lists.debian.org/debian-devel/2004/04/msg00080.html
 https://lists.debian.org/debian-devel/2005/02/msg00279.html

and

 https://bugs.debian.org/422139#151

I was not successful to convince fellows back then.

With having support for more than one init scheme, either all need to
implement the same interface (e.g. init scripts), or maintainers of
packages providing a service need to implement and possibly maintain
integrations into multiple init schemes.  Obvisiously that's not what's
desired.  Separating this integrations into different packages separates
personal resposibilities, interest, implementation and maintainance
effort.

Regards, Gerrit.

Is missing SysV-init support a bug?

[Jonathan de Boyne Pollard]

Russ Allbery:

But change sucks, and part of what accreted was decades of subtle 
workarounds to poorly-documented issues for which we have minimal 
institutional memory.


Like fulfilling the 1970s Unix promise of italics in manual pages, on 
the wide range of terminals that /can/ /do/ /italics/: stymied on Debian 
and only documented by a note at the bottom of a closed and forgotten 
bug report filed roughly a decade and a half ago against a long since 
superseded version.  A couple of Hitch-Hiker's Guide to the Galaxy 
quotations come to mind.


* https://jdebp.eu./Softwares/nosh/italics-in-manuals.html

Russ Allbery:

And the actual position appears to be something around "we're building 
it as separate components because that's just good engineering, but we 
don't particularly care about use cases that involve picking and 
choosing specific components and are not really prioritizing them," 
which is essentially perfectly positioned to make no one happy and all 
discussions around modularity arrive at frustratingly inconclusive 
loose ends.


This is another thing that falls under the umbrella of the world 
changing since 2014, note.  There have been discussions amongst the 
systemd developers about modularity, more recently.  They've been 
tentative and limited in scope, haven't resulted in any concrete outcome 
yet, and haven't filtered through to the Debian/Ubuntu world, but they 
have been there.


Russ Allbery:

I mostly pipe up here occasionally to poke at evidence from the 
"systemd is horrible" side [...] there's a bunch of nonsense on the 
pro-systemd side too [...]


I don't think that I've pointed you to this already, but if not you 
definitely need to read this:


* http://uselessd.darknedgy.net./ProSystemdAntiSystemd/

The same person (whose name I don't know) later wrote these:

* http://blog.darknedgy.net/technology/2015/09/05/0/

* http://blog.darknedgy.net/technology/2015/10/11/0/

Re: Is missing SysV-init support a bug?

[Nikolaus Rath]

On Aug 29 2016, Russ Allbery  wrote:
> Nikolaus Rath  writes:
>> On Aug 28 2016, Bart Schouten  wrote:
>
>>> But that's not the relevance. The idea that systemd is clearly superior
>>> to sysvinit is just something you concoct up because you don't know how
>>> to write a service file or script and you want to let systemd do the
>>> hard work.
>
>> How is that concoted? Yes, systemd is clearly superior to sysvinit
>> because it doesn't require me to know how to write a service file or
>> script but does the hard work for me.
>
> Python is clearly superior to C in that I don't have to do tedious memory
> management or worry about buffer overflows in allocated arrays.  Yet, I
> often prefer to implement things in C for a bunch of different reasons.  A
> couple of major ones are wanting more fine control and wanting a
> standalone binary that doesn't depend on an installed Python ecosystem.
>
> I disagree with both of you in that these aren't really "clearly superior"
> sorts of things, I think.  It feels like the wrong question entirely.

It seems I should have added an irony marker. My point was that the
quoted reasons support the statement just as well as its opposite and
was therefore pretty bogus, not that systemd is clearly superior.

And no, this email is also not stating that systemd is not clearly
superior.

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Is missing SysV-init support a bug?

[Holger Levsen]

Russ,

On Tue, Aug 30, 2016 at 01:24:44AM -0700, Russ Allbery wrote:
[...]
> It's kind of a perfect storm.  It makes sense if you sit down and
> enumerate the reasons, but it's still kind of amazing just how much of a
> perfect storm it is.

*g*

[...]
> TL;DR: I fear this init system is going to go on forever

nah, nothing is forever! :-) 5, 10 or 15 years maybe, I hope…

[...]
> But I do wish that people would acknowledge more of the above nuance when
> having this argument, and realize that the last thing we should ever do is
> claim that this decision is clear-cut or black and white.

Yes. Thanks a lot for taking the time to write this down. Except for the
tiny "forever" bit I much agree with what you wrote…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: libsystemd [was: Re: Is missing SysV-init support a bug?]

[Dmitry Bogatov]

[2016-08-29 18:30] Russ Allbery 
>
> part   text/plain1918
> Dmitry Bogatov  writes:
>
> > Socket is not bad thing. Inventing daemon for no reason is complicating
> > things for no reason => bad.  Thanks history, we have pid files, not
> > `libpid' to talk to `pidd'.
>
> Uh, the daemon in question is the init daemon?  Which has been there since
> the beginning of UNIX?  You kind of need that daemon.  You can't do
> without it.  :)

I know that pid 1 is daemon, that one must have. And this daemon, for
sake of simplicity, should just boot system.

I do not buy your argument, that since we already have daemon, lets just
put another optional functionality in it.

> PID files are an ugly hack and have *always* been an ugly hack.  I cannot
> tell you the number of obnoxious edge cases I've had to deal with around
> PID files: files getting created at the wrong time, with the wrong
> ownership, in directories that aren't writable by the process and
> therefore fail, with invalid contents, or truncated, or reused for some
> other purpose and now with bizarre and undocumented syntax, or kept around
> after the host reboots and they become irrelevant, or used entirely
> unsafely because the original daemon is long-gone, the PID space has
> wrapped, and now that PID is pointing to sshd and gets happily killed by
> something that blindly trusts the PID file.  They're not something anyone
> would want to use voluntarily.

I agree, that pid-files are not blessing, especially when we have
runit/daemontools/s6, which makes them unneeded.

But if I had to choose between pidfiles or linking to `libpid' to talk
with `pidd' (especially, if it is part of pid 1), I would choose
pidfiles.

> > I would be interested to know of more selling points of libsystemd, but
> > discussion how to implement them in simple way does not belong to
> > debian-devel, but to upstream projects lists.
>
> I'm discussing it on debian-devel because so many of the arguments against
> systemd on the grounds of its supposed contrariness to UNIX demonstrate
> the most appalling ignorance of UNIX, and I think it's useful to talk
> about *specifics* instead of general political positions on systemd as an
> abstract Platonian ideal.  We're making a free UNIX distribution.  We
> should care *deeply* about the specifics; that's the best way to make good
> decisions.  And we should be connoisseurs of good ideas, whatever their
> source.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Re: Is missing SysV-init support a bug?

[Russ Allbery]

Marc Haber  writes:
> Russ Allbery  wrote:

>> Debian historically tries to handle these situations by just providing
>> everything simultaneously.  The debate over init systems is as heated
>> as it is because it's quite difficult to do a good job at supporting
>> multiple init systems.

> And because it's a system-wide decision.

Yeah, that too, although I think that's somewhat less of a factor.  (But
it is a factor.)  Choosing your MTA or your cron daemon is also a
system-wide decision, but Debian supports tons of them and it's no big
deal.  The init system has several tricky factors, though:

1. Init systems by their very nature integrate with huge classes of
   software in the rest of the distribution, which is what makes it quite
   difficult to do a good job at supporting multiple init systems since
   there's quite a lot of work to do for each of them.  It's not quite as
   bad as supporting building Debian with multiple C compilers, but it's
   in that ballpark.

2. It's something that any experienced sysadmin is going to have to mess
   with, so it's not just something that Debian has to integrate, it's
   also something that has a lot of careful, tricky custom configuration
   done by the local administrator.  Who is obviously going to have strong
   opinions about how they work with it.

3. In the Debian context, it was a particularly stable (or stale,
   depending on how you want to spin it) part of the distribution.  Ubuntu
   had upstart, Red Hat had played with other init systems, but Debian
   largely hadn't.  So none of the muscles around "oh, this doesn't have
   to work exactly this way" were really being exercised.  (Yes, there was
   file-rc and a few other things, but the level of usage was miniscule.)
   So it's a wrenching transition to consider something else.

4. Managing daemons is something about which many of us have Opinions.
   Strong Opinions.  Please allow us to relate them to you.  They are
   quite Strong, and are Very Important, and we have Thought About Them A
   Great Deal, and your opinions, if they differ, are probably Wrong.
   Managing daemons is to sysadmins what editors are to programmers.  We
   spend lots of time with that software.  Opinions form.

5. It is arguable what the init system can or should do.  By that, I mean
   that some people think the init system should do quite a lot more than
   it historically had done, because there was a bunch of stuff being done
   poorly and inconsistently that benefits greatly from being
   standardized.  And other people who believe that, if anything, the
   problem with sysvinit was that it was doing too much and was too
   complex.  And neither of these people are obviously wrong.  Depending
   on what angle you look at things from, you can make a lot of strong
   arguments all around.  It's much like the debate between writing
   software in some very high-level language like Python versus writing
   it in C, as mentioned in my other message.

6. systemd muddled this considerably because it's not only an init system
   project, it's an operating system plumbing project whose contributors
   are very excited to fix what they view as a wide variety of historical
   warts and suboptimal solutions to a ton of various low-level plumbing
   and integration issues.  This is simultaneously exciting and scary.
   (And I'm going to go out on a limb here and say that if you find it
   only exciting, or if you find it only scary, you are not thinking
   enough about it, are missing significant components of this effort, and
   should really think about it some more until you can recognize both
   halves of that reaction and why they both make sense.)

   There is a bunch of low-level plumbing deep inside UNIX and Linux that
   is, to be frank, archaic, cobbled-together bullshit, and that I think
   we'd all admit was that if it came up in a context outside of a very
   heated and divisive debate.  Modern thinking on component separation,
   configuration syntax, APIs, and the usefulness of things like event
   buses are, shall we say, informed by decades of experience, much
   broader communities and more varied goals, and a huge developer base,
   compared to what the original designers of UNIX had available.  It's
   not at all hubris to look at the icky guts of OS plumbing, particularly
   the bits that were never really designed but just accreted over the
   years, and think "this could be a lot better if it were properly
   designed for modern systems and problems."  But change sucks, and part
   of what accreted was decades of subtle workarounds to poorly-documented
   issues for which we have minimal institutional memory.  If
   contemplating replacing that stuff doesn't terrify you from a stability
   and disruption standpoint, you're not thinking about it hard enough.

7. systemd upstream sits at the perfect inflection point between
   insufficiently good at 

Re: Is missing SysV-init support a bug?

[Marc Haber]

On Mon, 29 Aug 2016 20:18:49 -0700, Russ Allbery 
wrote:
>Debian historically tries to handle these situations by just providing
>everything simultaneously.  The debate over init systems is as heated as
>it is because it's quite difficult to do a good job at supporting multiple
>init systems.

And because it's a system-wide decision.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Is missing SysV-init support a bug?

[Russ Allbery]

Nikolaus Rath  writes:
> On Aug 28 2016, Bart Schouten  wrote:

>> But that's not the relevance. The idea that systemd is clearly superior
>> to sysvinit is just something you concoct up because you don't know how
>> to write a service file or script and you want to let systemd do the
>> hard work.

> How is that concoted? Yes, systemd is clearly superior to sysvinit
> because it doesn't require me to know how to write a service file or
> script but does the hard work for me.

Python is clearly superior to C in that I don't have to do tedious memory
management or worry about buffer overflows in allocated arrays.  Yet, I
often prefer to implement things in C for a bunch of different reasons.  A
couple of major ones are wanting more fine control and wanting a
standalone binary that doesn't depend on an installed Python ecosystem.

I disagree with both of you in that these aren't really "clearly superior"
sorts of things, I think.  It feels like the wrong question entirely.

Personally, I think the systemd unit file syntax is a significant feature,
since I'm very tired of tedious, buggy shell boilerplate.  Many people
have the same feeling about languages with automatic memory management and
garbage collection, or about exceptions versus return status codes.  But
these aren't unambiguous design decisions.  There are tradeoffs, and where
there are tradeoffs, there will be things one system or another isn't as
well-suited for.

Part of what systemd does explicitly is try to constrain the design space
by choosing not to support certain things in an attempt to make the
overall system much simpler.  This is a very common approach with
programming languages as well; in a way, you could argue that every
programming language that isn't assembly limits the freedom of the
programmer in order to make the system simpler and more consistent.  My
day job is in security, which gives one a real appreciation of the merits
of making dangerous things impossible to do and limiting the possibility
surface.  But it's always a very controversial thing to do, since there
are always reasons for doing the thing that's normally quite dangerous, or
tedious, to do.

This is one of those arguments that you're never going to resolve either
way, since it's not a question of objective merit.  It's a question of two
competing design principles that are inherently in tension.  You can find
various different compromises between them that will be better at one
thing and worse at another thing, but you're never going to resolve the
conflict and be able to say that one approach is clearly better than the
other in all respects.

Debian historically tries to handle these situations by just providing
everything simultaneously.  The debate over init systems is as heated as
it is because it's quite difficult to do a good job at supporting multiple
init systems.

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

Re: Is missing SysV-init support a bug?

[Nikolaus Rath]

On Aug 28 2016, Bart Schouten  wrote:
> But that's not the relevance. The idea that systemd is clearly
> superior to sysvinit is just something you concoct up because you
> don't know how to write a service file or script and you want to let
> systemd do the hard work.

How is that concoted? Yes, systemd is clearly superior to sysvinit
because it doesn't require me to know how to write a service file or
script but does the hard work for me. 


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Is missing SysV-init support a bug?

[Simon Richter]

Hi,

On 28.08.2016 14:29, Jonathan de Boyne Pollard wrote:

> especially in light of the fact
> that the systemd developers have had a list of "Oddball things that you
> can actually do with rc scripts that systemd isn't going to support."

The crux of the matter is that what the majority thinks of as an
"oddball" configuration is someone's production system.

When systemd "isn't going to support" an interface from sysvinit, that
is a technical decision their project makes, and usually for good
reasons (I've written a lengthy article[1] about this).

However, Debian is not the systemd project. What is good project
management for them is not necessarily what is best for our users.

I agree that to the vast majority of users, this is entirely
inconsequential, as they haven't modified their init scripts at all, and
probably do not know about their existence. These people were served
well with sysvinit as default before jessie, and even better now with
systemd as default.

But we still have other users, some of who disagree with the
architectural model of systemd, as the tight integration and ease of use
was bought with a reduction in flexibility.

The same debate comes up with build systems occasionally, and it leads
nowhere there either:

When you use make, you have to remember a lot of arcane syntax
(mandatory tab indentation, single-punctuation-character variable names)
and put together the command line for your compiler in a scripting language.

Then there is autoconf. You still write Makefiles, you get another layer
of arcane syntax on top, but you get a lot of support code that is
shared with other projects, so now it becomes easier to support cross
compiling and different compilers.

Then someone wrote automake, after realizing that most Makefiles look
the same anyway. You compile some code, track include file dependencies,
link the generated objects together and install the result somewhere, so
all that is different between project is the names of the source and
output files.

Then, cmake comes along. They bring this to another level, and even
allow you to generate project files for graphical IDEs.

However, with each improvement there was a trade-off involved:

 - autoconf added easy cross-compiling, but also the assumption that
only a single compiler would be used in one source tree, which was
annoying for embedded projects that would build firmware along with drivers.

 - automake dropped support for anything that wasn't a program or
library, telling people to use plain autoconf in a subdirectory then.

 - cmake dropped the option to fall back on scripted builds, and their
cross compiling support sucks.

If you look at a modern Linux system, you will find that the majority of
the software we have are programs and libraries, and that many of these
have switched to cmake as their build system in the last years.

Still, the kernel uses plain "make", not cmake.

I use cmake for most of my projects, but one of them has a program that
runs on the host CPU that talks to a kernel module that downloads a
bitstream into an FPGA that contains an embedded ARM CPU that runs a
statically linked program. That project uses a Makefile for the kernel
module, automake for the userspace drivers and autoconf for finding the
FPGA toolchain, and configures the ARM cross-compiler in a subdirectory.

This is my yardstick: If you propose to exclusively use a single,
easy-to-use build system with good integration into graphical IDEs, I
request that you show that it can also build both the Linux kernel and
my module from source on all currently supported architectures, and you
guarantee that my project won't break by any future updates of the build
system.

Otherwise, your build system is useless for my project. I may still use
it for the majority of my other projects, because it may be convenient
to use, but I will laugh at you if you claim that I don't need any others.

The same goes for init systems, really. It is completely fine if you
prefer systemd. It is also true that my laptop runs systemd, because I
don't care as long as it works. Neither of these invalidates the use
cases I or other people have that are better served by sysvinit. It is
pretty clear that systemd cannot ever handle these use cases, nor should
it attempt to.

This entire debate is really about the scope of the Debian project, so
this is not a technical decision that has a "right" answer. Either
choice we make here is going to hurt -- either we have to invest extra
work to continue sysvinit support, or we cease to be the "universal"
operating system as we drop support for quite a lot of embedded systems
currently running Debian or derivatives.

I think it is important to realize that a simple majority vote will not
get a satisfactory result here either. The majority does not care. We
have two factions with strong opinions and good arguments from their
respective points of view, and we need to find common ground.

In my opinion, Debian's strength used 

Re: libsystemd [was: Re: Is missing SysV-init support a bug?]

[Russ Allbery]

Dmitry Bogatov  writes:

> Socket is not bad thing. Inventing daemon for no reason is complicating
> things for no reason => bad.  Thanks history, we have pid files, not
> `libpid' to talk to `pidd'.

Uh, the daemon in question is the init daemon?  Which has been there since
the beginning of UNIX?  You kind of need that daemon.  You can't do
without it.  :)

PID files are an ugly hack and have *always* been an ugly hack.  I cannot
tell you the number of obnoxious edge cases I've had to deal with around
PID files: files getting created at the wrong time, with the wrong
ownership, in directories that aren't writable by the process and
therefore fail, with invalid contents, or truncated, or reused for some
other purpose and now with bizarre and undocumented syntax, or kept around
after the host reboots and they become irrelevant, or used entirely
unsafely because the original daemon is long-gone, the PID space has
wrapped, and now that PID is pointing to sshd and gets happily killed by
something that blindly trusts the PID file.  They're not something anyone
would want to use voluntarily.

> I would be interested to know of more selling points of libsystemd, but
> discussion how to implement them in simple way does not belong to
> debian-devel, but to upstream projects lists.

I'm discussing it on debian-devel because so many of the arguments against
systemd on the grounds of its supposed contrariness to UNIX demonstrate
the most appalling ignorance of UNIX, and I think it's useful to talk
about *specifics* instead of general political positions on systemd as an
abstract Platonian ideal.  We're making a free UNIX distribution.  We
should care *deeply* about the specifics; that's the best way to make good
decisions.  And we should be connoisseurs of good ideas, whatever their
source.

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

Re: libsystemd [was: Re: Is missing SysV-init support a bug?]

[Dmitry Bogatov]

> > I can understand this need, although never needed it myself.
>
> > But implementation makes me sad. Instead of creating UNIX-way solution
> > (create /var/run/foo.ready, when you are ready?), it does the worst
> > thing I can imagine.
>
> If communicating with another local daemon via a UNIX domain socket is the
> worst thing that you can imagine, you don't have a very good imagination.
> :)

Socket is not bad thing. Inventing daemon for no reason is
complicating things for no reason => bad.  Thanks history, we have pid
files, not `libpid' to talk to `pidd'.

I would be interested to know of more selling points of libsystemd,
but discussion how to implement them in simple way does not belong to
debian-devel, but to upstream projects lists.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Re: Is missing SysV-init support a bug?

[Simon Richter]

Hi,

On 28.08.2016 22:11, Bart Schouten wrote:

> That "very serious race condition" is nothing more than one daemon
> having to wait for the other while starting up. THAT'S IT. Oh and
> knowing when something has died so you can restart it or something.

That is also something the init system can not really fix, just paper over.

Any daemon that is dependent on another to work needs to be able to
handle the case where the other process is restarted, or fails for some
reason, and provide error recovery in this case. Declaring a dependency
in a systemd unit file is no better in that regard than simply ordering
daemons by priority, and ideally the daemon needs to be resilient enough
to work even if the other daemon is started with no synchronisation or
if timed jobs are simply not run.

I'd also postulate that these error cases are not properly tested in
most daemons we have. Every service can always fail due to transient
errors, and this needs to be communicated up the stack. There is a
reason why SMTP daemons will first write a mail to disk, flush the
caches, and only then acknowledge receipt.

   Simon



signature.asc
Description: OpenPGP digital signature

Re: libsystemd [was: Re: Is missing SysV-init support a bug?]

[Russ Allbery]

Vincent Bernat  writes:
>  ❦ 29 août 2016 05:00 CEST, Russ Allbery  :

>> upstart supports a similar mechanism via the -Z flag, but it's (IMO) a
>> little less clean: the process sends itself a SIGSTOP when it's ready,
>> and then lets the init system send it a SIGCONT.  This does work, but I
>> don't like it as much; pausing for the init system is awkward, you have
>> to remember to omit the flag when running the daemon manually for
>> debugging

> You can look at the UPSTART_JOB environment variable to determine if you
> are running from Upstart or not.

You can't, really, because it's an environment variable, so it will get
inherited by things run by upstart jobs but that are not themselves
upstart jobs.  It's a 90% solution that fails in edge cases.  (The world
of init systems is full of stuff like that.  It's very frustrating.)

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

Re: libsystemd [was: Re: Is missing SysV-init support a bug?]

[Russ Allbery]

Dmitry Bogatov  writes:

> I can understand this need, although never needed it myself.

> But implementation makes me sad. Instead of creating UNIX-way solution
> (create /var/run/foo.ready, when you are ready?), it does the worst
> thing I can imagine.

If communicating with another local daemon via a UNIX domain socket is the
worst thing that you can imagine, you don't have a very good imagination.
:)  That's been a long-standing, very UNIX-y way of doing things like this
dating back literally decades.  (When was INN 1.0?  1994?  I think BIND
may have done something similar even earlier.)

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

Re: Is missing SysV-init support a bug?

[Marco d'Itri]

The fun thing is that if the original poster had just shipped an 
half-broken script nobody would have ever noticed, and in a couple of 
years it would have been another data point about the irrelevance of 
sysvinit nowadays.

As long as the package builds, don't bother... :-)

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Is missing SysV-init support a bug?

[Dmitrii Kashin]

"Adam D. Barratt"  writes:

> No. Policy is not a user-focused tool, it's the documentation of how
> developers / maintainers are expected to build packages. It documents
> how things are and the current conventions, not how they will or might
> be at some hypothetical point in the future.

Okay, it seems that I have mistaken. Sorry and thank you for the correction.

Re: Is missing SysV-init support a bug?

[Adam D. Barratt]

On Mon, 2016-08-29 at 13:12 +0300, Dmitrii Kashin wrote:
> Don Armstrong  writes:
[...]
> > Policy is not a tool to beat developers with; it's a method of
> > documenting convention so that we can build a distribution of packages
> > which interact. Like most documentation of convention, it tends to lag
> > behind when convention changes.
> 
> These conventions *must* be mentioned in policy specifically *before*
> the changes according them are made. Policy is not only the place to
> document conventions but it's also the way to inform end-users about
> changes in their distribution.

No. Policy is not a user-focused tool, it's the documentation of how
developers / maintainers are expected to build packages. It documents
how things are and the current conventions, not how they will or might
be at some hypothetical point in the future. By extension, where a
change that affects a large number of packages is being made, the
expectation is that the majority of packages are updated first and then
Policy is brought up-to-date; operating in the reverse manner would risk
making much of the distribution instantly non-compliant.

(The majority of changes to Policy have no direct effect on users, and a
significant number of changes in the distribution that affect users will
be related to updated versions of software and therefore not mentioned
in Policy at all.)

> So if end-user disagree he can take part in discussion and try to
> explain his position to developer community. Or he can decide to switch
> to another distribution before his current distro accepts these policy
> changes.

Once the change is documented in Policy it *is* accepted, by definition;
it's part of Policy.

> I mean users must be warned before the changes are applied, certainly
> not after. And therefore Policy is the tool to beat developers with.

Users are warned of changes in the Release Notes of each release, not
through Policy. Policy is a description of conventions, not a means of
keeping people in line.

Regards,

Adam

Re: Is missing SysV-init support a bug?

[Dmitrii Kashin]

Didier 'OdyX' Raboud  writes:

> Le lundi, 29 août 2016, 12.07:23 h CEST Dmitrii Kashin a écrit :
>> But I know a lot of them. And not only in Debian community. And they
>> don't agree that migrating will give them greater control over their
>> systems.
>
> This is not a popularity contest, in which we'd count points either way. We, 
> as the Debian community, are discussing what we want to offer to our users, 
> given our interests, capabilities, and manpower. Mobs don't produce patches.

I can't agree that the opinion of mobs hasn't be heared. It always
seemed that Debian project is aimed to be a *universal* OS and tends to
provide with good solutions for quite a large user group. If we don't
want to consider their interests so we are on the way to become a
distribution for small groups of hackers.

And I know "mobs" that actually produce patches. Well I think I must at
least attract an attention to this thread in debian-russian mailing
list. This is the best think I could do for the discussion.

Re: Is missing SysV-init support a bug?

[Didier 'OdyX' Raboud]

Le lundi, 29 août 2016, 12.07:23 h CEST Dmitrii Kashin a écrit :
> But I know a lot of them. And not only in Debian community. And they
> don't agree that migrating will give them greater control over their
> systems.

This is not a popularity contest, in which we'd count points either way. We, 
as the Debian community, are discussing what we want to offer to our users, 
given our interests, capabilities, and manpower. Mobs don't produce patches.

> If you want I'll ask them to write here too.

Please don't.

-- 
Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Is missing SysV-init support a bug?

[Dmitrii Kashin]

Don Armstrong  writes:

> On Mon, 29 Aug 2016, Dmitrii Kashin wrote:
>> If we assume that this precedent allow a maintainer to violate policy,
>> so we don't need the Policy anymore.
>
> Violating policy is still a bug; it may be a bug in policy, or a bug in
> the package.
>
>> they still continue to rely on Policy to be sure that somebody takes
>> care of their interests.
>
> Policy is not a tool to beat developers with; it's a method of
> documenting convention so that we can build a distribution of packages
> which interact. Like most documentation of convention, it tends to lag
> behind when convention changes.

These conventions *must* be mentioned in policy specifically *before*
the changes according them are made. Policy is not only the place to
document conventions but it's also the way to inform end-users about
changes in their distribution.

So if end-user disagree he can take part in discussion and try to
explain his position to developer community. Or he can decide to switch
to another distribution before his current distro accepts these policy
changes.

I mean users must be warned before the changes are applied, certainly
not after. And therefore Policy is the tool to beat developers with.

Re: Is missing SysV-init support a bug?

[Don Armstrong]

On Mon, 29 Aug 2016, Dmitrii Kashin wrote:
> If we assume that this precedent allow a maintainer to violate policy,
> so we don't need the Policy anymore.

Violating policy is still a bug; it may be a bug in policy, or a bug in
the package.

> they still continue to rely on Policy to be sure that somebody takes
> care of their interests.

Policy is not a tool to beat developers with; it's a method of
documenting convention so that we can build a distribution of packages
which interact. Like most documentation of convention, it tends to lag
behind when convention changes.

-- 
Don Armstrong  https://www.donarmstrong.com

Let me bring you up to speed:
We know nothing.
You are now up to speed.
  -- Steve Martin as Inspector Clouseau in _The Pink Panther 2_ (2009)

Re: Is missing SysV-init support a bug?

[Dmitrii Kashin]

But I know a lot of them. And not only in Debian community. And they
don't agree that migrating will give them greater control over their
systems.

If you want I'll ask them to write here too.

Attila Kinali  writes:

> On Thu, 25 Aug 2016 19:47:55 -0400
> Robert Edmonds  wrote:
>
>> I would guess that the vast majority of folks still using sysvinit with
>> Debian are running wheezy or older, and thus removing sysvinit scripts
>> from packages in unstable wouldn't affect them. But maybe that still
>> leaves a reasonable number of testing/unstable + sysvinit users.
>
> Not true. I know quite a few people running server systems, who stick
> to sysV for simplicity reasons (having greater control over your system
> is a big plus there). 
>
>   Attila Kinali

Re: Is missing SysV-init support a bug?

[Dmitrii Kashin]

Philipp Kern  writes:

> On 2016-08-26 19:53, Wookey wrote:
>> After Stretch there may not be that many sysvinit users, but I think
>> that 2 releases is the minimum sensible period to maintain support for
>> such a siginificant change.
>
> But it seems that this discussion does not consider if sysvinit
> support in the conntrackd package is useful for the remaining sysvinit
> users or not. It seems to be more of a knee-jerk reaction to the
> removal, as in "we can't let that happen" because of some kind of
> assumed policy that hasn't been updated. It's one thing to assume
> precedent everywhere and let the maintainer actually determine what's
> the best for the package. Rather than users finding out the caveats
> mentioned in [1] the hard way by deploying the package on sysvinit.

If we assume that this precedent allow a maintainer to violate policy,
so we don't need the Policy anymore.

Does not matter if this package is useful for sysvinit users. Users are
maybe just not here. They may not even be developers. But they still
continue to rely on Policy to be sure that somebody takes care of their
interests.

Re: libsystemd [was: Re: Is missing SysV-init support a bug?]

[Dmitry Bogatov]

[2016-08-28 20:00] Russ Allbery 
>
> part   text/plain3207
> Dmitry Bogatov  writes:
>
> > Not to start flame or to advertize anything/anyone, but why to integrate
> > with 'runit' init system, your program should support foreground
> > operation and logging on stdout, and to integrate with systemd, it
> > should link with library?
> [...]
>
> To integrate with systemd, you don't have to use a library.  However, the
> library lets you do some really cool stuff that makes a systemd system
> work more reliably.  Most importantly (although not solely), it lets you
> explicitly tell systemd exactly when the daemon has fully started, so that
> the init system doesn't have to guess.

I can understand this need, although never needed it myself.

But implementation makes me sad. Instead of creating UNIX-way solution
(create /var/run/foo.ready, when you are ready?), it does the worst
thing I can imagine.

Thanks for sharing experience.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Re: libsystemd [was: Re: Is missing SysV-init support a bug?]

[Vincent Bernat]

 ❦ 29 août 2016 05:00 CEST, Russ Allbery  :

> upstart supports a similar mechanism via the -Z flag, but it's (IMO) a
> little less clean: the process sends itself a SIGSTOP when it's ready, and
> then lets the init system send it a SIGCONT.  This does work, but I don't
> like it as much; pausing for the init system is awkward, you have to
> remember to omit the flag when running the daemon manually for
> debugging

You can look at the UPSTART_JOB environment variable to determine if you
are running from Upstart or not.
-- 
Instrument your programs.  Measure before making "efficiency" changes.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: libsystemd [was: Re: Is missing SysV-init support a bug?]

[Russ Allbery]

Dmitry Bogatov  writes:

> Not to start flame or to advertize anything/anyone, but why to integrate
> with 'runit' init system, your program should support foreground
> operation and logging on stdout, and to integrate with systemd, it
> should link with library?

You should *also* support foreground operation and logging on stdout with
systemd.  Any modern daemon should support that mode of operation at least
as an option.  (I've been pushing for that for fifteen years, well before
systemd started, since it makes a lot of daemon management much easier
once you have something more sophisticated than rc.d shell scripts.  I
think djb's daemontools was one of the early advocates of this approach,
but I suspect other people had independently invented the idea earlier.)

To integrate with systemd, you don't have to use a library.  However, the
library lets you do some really cool stuff that makes a systemd system
work more reliably.  Most importantly (although not solely), it lets you
explicitly tell systemd exactly when the daemon has fully started, so that
the init system doesn't have to guess.  All other init systems except
upstart have to either guess or use a pretty awkward external signal
(generally creation of a PID file on disk, which is otherwise useless if
your init system tracks processes correctly and your daemon can run in the
foreground).  The guesses are often pretty bad, and a lot of daemons don't
create the PID file at the right place because of various internal
reasons.  With systemd, this is nicely explicit.

This, in turn, helps prevent a lot of irritating startup order race
conditions and awkwardness, which under sysvinit caused Debian to have a
bunch of "sleep N" commands embedded in init scripts to work around these
races.  This was always ugly, and had been something the distribution
wanted to get rid of for a long time.

upstart supports a similar mechanism via the -Z flag, but it's (IMO) a
little less clean: the process sends itself a SIGSTOP when it's ready, and
then lets the init system send it a SIGCONT.  This does work, but I don't
like it as much; pausing for the init system is awkward, you have to
remember to omit the flag when running the daemon manually for debugging
or you get really strange and unexpected behavior, and I think most
long-time UNIX programmers have been burned by weird interactions with
signals and are aware of how tricky they can be to use properly around
event loops.  systemd uses a UNIX domain socket (and you can implement the
code yourself if you want, but the library makes it super-convenient and
is well-tested code that other people maintain for you), which I think is
a cleaner solution.  The point is admittedly arguable.

There's other stuff, like socket activation, that can be useful in some
situations, but the explicit notification protocol was what sold me on
adding optional libsystemd dependencies to the daemons I maintain.  It's
really a better solution than the other available options (which, to be
clear, I also support as upstream, because that's my general philosophy on
such things).

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

Re: Is missing SysV-init support a bug?

[Philipp Kern]

On 2016-08-28 16:11, Bart Schouten wrote:

Unnamed issues that are made to appear HUGE. And they are so simple
and so small, a child could do it. (I like did that sort of thing when
I was 14 or 15). (But it was like assembler and pascal and writing
interrupt handlers and being awesome ;-)).


Then I'd suggest to help out the maintainer writing it. Because the 
burden here should then not be on the maintainer, surely? And it's not 
just writing that takes time, it's also testing. In which case we're 
back to square one with "I don't have a system to test it, I know it's 
broken, there seems to be noone else out there who cares enough to fix 
it"?


Kind regards
Philipp Kern

Re: libsystemd [was: Re: Is missing SysV-init support a bug?]

[Dmitry Bogatov]

[2016-08-28 06:26] Adam Borowski 
>
> part   text/plain2020
> On Sat, Aug 27, 2016 at 10:33:36AM +0300, Dmitry Bogatov wrote:
> > > > I hugely support idea of dynamically loading libsystemd.
> > >
> > > Please don't, no.  While I do think packages should keep sysvinit
> > > support as long as it continues to work and doesn't make other paths
> > > worse, I don't think it makes sense to omit linking to libsystemd, or to
> > > dlopen it at runtime.
> >
> > Extra useless dependency. This is case when I miss Gentoo's use-flags.
>
> But _why_ would you want to avoid libsystemd?  Its only bad effect is
> wasting a negligible amount of disk space and a few pages memory.  Do you
> recompile for example clementine/amarok/rhythmbox/banshee without libgpod
> just because you don't own such an ancient piece of iCrap?  Unless you go
> really deeply embedded, fighting such slight bloat is not worth your time.

I am not member, but I share this manifest [http://suckless.org/philosophy].

I do not use clementine/amarok/... stuff. I didn't knew about libgpod,
dependency on X to just play music is already too much for me.

Question is not megabytes. Question is Right Thing. And systemd moves
wrong direction -- to complexity, not simplicity. Why should I care
about program I do not use?

But also it affects things I do care of -- programs I use every day.
And somehow systemd project seduces them. (Damn, even tor is now
conditionally depends on libsystemd.)

I do not see how can I prevent it, but I do my best to protect myself
from this complexity madness. Thanks to Debian, I can do it. It's like
moving to Gentoo, but better.

> [41270.363362] Killed process 14533 (firefox) total-vm:3598348kB,

I do not use it either. Firefox does not affects in any way 'surf' or 'w3m',
which I use.

> > If I don't like libsystemd dependency, I am in much worse position,
> > since I have to rebuild really a lot of packages. Yes, we have
> > `angband.pl' repository, but this not systematic solution.
>
> As I'm the guy behind that repository, my reason for recompiling everything
> without libsystemd is not pruning this small dependency -- it's a cheap way
> to ascertain programs use non-systemd code paths.

I agree with this target.

> It'd be nice if all of them did the detection at runtime, but
> unfortunately some (like policykit-1) have mutually exclusive code
> paths that get chosen at compile time.  By compiling with no systemd
> libraries, I can be sure all such pitfalls are avoided.  But that's
> only a short-term gain.

Runtime detection... complexity, complexity again.

Not to start flame or to advertize anything/anyone, but why to
integrate with 'runit' init system, your program should support
foreground operation and logging on stdout, and to integrate with
systemd, it should link with library?

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Re: Is missing SysV-init support a bug?

[Tollef Fog Heen]

]] Bart Schouten 

> You will now demonstrate your superiority by claiming you know the
> better spelling?

It has nothing to do with superiority.  It's just that it's a tad tiring
to see it misspelled, just like it gets tiring to see people write
Micro$oft and other similar «funny» misspellings.

If you don't want to detract from your message, don't add intentional
speed bumps to it.

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

Re: Is missing SysV-init support a bug?

[Bart Schouten]

Andrey Rahmatullin schreef op 28-08-2016 22:06:

On Sun, Aug 28, 2016 at 09:23:58PM +0200, Bart Schouten wrote:

> You'll be doing yourself a favour.  For better or for worse, the
> mis-spelling has become a shibboleth by which people tend to recognize
> mischievous pot-stirrers at a glance.

Oh please.

You will now demonstrate your superiority by claiming you know the 
better

spelling?

You've missed the point, sadly.


That's another way to claim that you're superior to me isn't it?

Re: Is missing SysV-init support a bug?

[Bart Schouten]

Philipp Kern schreef op 28-08-2016 12:41:


http://ral-arturo.blogspot.com/2016/08/why-conntrackd-in-debian-is-better-with.html


I am sorry I allowed myself to be drawn into this.

That "severely broken init script" is thus nothing more serious than any 
other script out there, and the "very bad race condition" is one of the 
most simple problems to solve, and has long since been solved by 
probably every package out there in whatever way.


It is also the basic gist of what SystemD provides of course, but it is 
not like this is a new world problem of any kind.


That "very serious race condition" is nothing more than one daemon 
having to wait for the other while starting up. THAT'S IT. Oh and 
knowing when something has died so you can restart it or something.


Of course running backgrounds scripts that do this sort of thing is 
perhaps not the most elegant thing to do, but that was not the point 
here. The point was that it was "severely broken" or something of the 
kind. And all that was required was a form of status notification that 
you could really whip up in two hours at the base, and, seeing how 
programming goes, would take a lot longer to fine-tune, but not a world 
class problem here.


How can people seriously use words such as "very bad race condition" and 
"really poor" to the point that you need to "use systemd to reliably use 
conntrackd as a daemon" (paraphrased) when that situation could be 
resolved with 2 hours of writing... at least to the point of 
satisfaction to not be having to call it "really poor" anymore. And that 
"SystemD's superiority" is a self-created thing here. "no serious 
implementation would use sysvinit". Perhaps, but no serious 
implementation would use SystemD either.


But that's not the relevance. The idea that systemd is clearly superior 
to sysvinit is just something you concoct up because you don't know how 
to write a service file or script and you want to let systemd do the 
hard work. Yes, I mean systemd as a daemon. A name and a binary package 
or binary file are two different things. We don't have to call 
everything by their binaries, not at all.


Bash programming is not hard, at least not for me, dash programming is 
somewhat harder but with the tools you can do everything. The only thing 
difficult and incomprehensible about bash is redirects. I mean the exec 
style and changing one channel into another.


But to think that such a simple and rudimentary software design and 
software engineering problem would be considered reason enough to call 
one piece of software superior to another, is beyond me.


And it's just a sorry state of affairs form my point of view. I mean, 
where is the software quality here? Do we always have to put up with 
such crap?


I have been programming since I was 12 and I have won tournaments. Well, 
only one, my friends did the rest in a sense. And I am just amazed at 
how such important words are used for such simple things.


And I just don't really want to have anything to do with that, I am 
sorry I came here. Blowing things up and making something sound very 
important when it is not. Simple problems that can be solved in an hour 
or two (if you are already the one who has invested in the software, of 
course, which obviously any random person cannot and will not do).


And perhaps a better solution would take more work, but still that is 
just the same.


I will go stick my head in some  hole again, sorry I was here ;-). 
Still, you are more rational, more clear, more to the point, and more 
concise people than what I have seen so far around the waters.


But having such a huge debate from that point of view, over the most 
rudimentary of software engineering difficulties, that are not named 
until they are put in that blog post.


Unnamed issues that are made to appear HUGE. And they are so simple and 
so small, a child could do it. (I like did that sort of thing when I was 
14 or 15). (But it was like assembler and pascal and writing interrupt 
handlers and being awesome ;-)).


And I just wonder how many times I am fooled by something that some 
person uses big words for to describe great difficulty and stuff that is 
impossible and hard to get around and sufficient and adequate reasons to 
call something Necessity. And then when you get down to it you know you 
could get around it in an instant.


Necessity yes. Such a foolish word at times, mostly.

Only the fools believe in the Necessity of things, I guess.

Well let me be the fool then and consider that I need to learn more 
about my own inadequacies before I start to name those of others ;-). 
Bye I guess, once more, I don't know.


See ya.

Re: Is missing SysV-init support a bug?

[Andrey Rahmatullin]

On Sun, Aug 28, 2016 at 09:23:58PM +0200, Bart Schouten wrote:
> > You'll be doing yourself a favour.  For better or for worse, the
> > mis-spelling has become a shibboleth by which people tend to recognize
> > mischievous pot-stirrers at a glance.
> 
> Oh please.
> 
> You will now demonstrate your superiority by claiming you know the better
> spelling?
You've missed the point, sadly.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Is missing SysV-init support a bug?

[Bart Schouten]

Jonathan de Boyne Pollard schreef op 28-08-2016 13:56:

Bart Schouten:


Personally I do not run a non-SystemD system, [...]


Then please spell the name correctly.  It is no more "SystemD" than
inetd is "INetD" or rsyslogd is "RSysLogD".  It is "systemd".

You'll be doing yourself a favour.  For better or for worse, the
mis-spelling has become a shibboleth by which people tend to recognize
mischievous pot-stirrers at a glance.


Oh please.

You will now demonstrate your superiority by claiming you know the 
better spelling?

Is missing SysV-init support a bug?

[Jonathan de Boyne Pollard]

Arturo Borrero González:

 * systemd is starting to drop support for some sysvinit mechanisms 
[https://sources.debian.net/src/systemd/231-4/debian/systemd.NEWS/]



Don't employ such thinking.  It is a mistake; in two ways no less.

Close on the heels of the Debian Technical Committee's decision about 
systemd being the default, one Debian package maintainer thought as you 
are thinking.  If systemd was the now the default, xe could drop the van 
Smoorenburg rc scripts from xyr packages.  A furore resulted, the 
outcome of which has already been mentioned in this discussion.


You also need to look at what Debian systemd is dropping support for.  
Is your rc script a run-level "S" script?  No, it is not. What makes you 
think that what is being announced for systemd 231 on Debian even 
applies to your package?  It is a mistake to make superficial and glib 
analyses that systemd not supporting a very specific thing is somehow 
systemd not supporting anything at all; especially in light of the fact 
that the systemd developers have had a list of "Oddball things that you 
can actually do with rc scripts that systemd isn't going to support." 
for several years, now.  Ironically, not supporting run level "S" has 
been on that list for a long time.  What's happening is actually that 
Debian's special exception is being taken away.


* https://wiki.debian.org/Teams/pkg-systemd/rcSMigration

* https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/

* https://jdebp.eu./FGA/systemd-documentation-errata.html#SingleUserRunLevel

Is missing SysV-init support a bug?

[Jonathan de Boyne Pollard]

Bart Schouten:


Personally I do not run a non-SystemD system, [...]

Then please spell the name correctly.  It is no more "SystemD" than 
inetd is "INetD" or rsyslogd is "RSysLogD".  It is "systemd".


You'll be doing yourself a favour.  For better or for worse, the 
mis-spelling has become a shibboleth by which people tend to recognize 
mischievous pot-stirrers at a glance.

Re: Is missing SysV-init support a bug?

[Philipp Kern]

On 2016-08-26 19:53, Wookey wrote:

After Stretch there may not be that many sysvinit users, but I think
that 2 releases is the minimum sensible period to maintain support for
such a siginificant change.


But it seems that this discussion does not consider if sysvinit support 
in the conntrackd package is useful for the remaining sysvinit users or 
not. It seems to be more of a knee-jerk reaction to the removal, as in 
"we can't let that happen" because of some kind of assumed policy that 
hasn't been updated. It's one thing to assume precedent everywhere and 
let the maintainer actually determine what's the best for the package. 
Rather than users finding out the caveats mentioned in [1] the hard way 
by deploying the package on sysvinit.


Apart from the concerns around popcon being representative or not 
(although do note that we rely on the data in many places like 
determining key packages) it would be helpful sometimes to be able to 
slice and dice the data into "how many users do have sysvinit as their 
init system and use this package". Alas, AFAIU that's not possible 
today.


Kind regards
Philipp Kern

[1] 
http://ral-arturo.blogspot.com/2016/08/why-conntrackd-in-debian-is-better-with.html

Fixing the Debian Policy Manual to finally reflect changes from 2014 (was: "Is missing SysV-init support a bug?" on debian-devel)

[Jonathan de Boyne Pollard]

Robert Edmonds:


The relevant text from the policy manual, §9.11: [...]

The Debian Policy Manual never got updated in the wake of the Debian 
systemd Hoo-Hah.  It remains written from the viewpoint that System 5 
init and rc are the defaults, and that upstart is a novelty addendum.  
Several people in 2014 publicly proposed starting a Policy Manual 
revision.  They never finished, to my knowledge, and their proposals 
remain part-done (to this day, as far as I know, although I haven't 
re-checked since 2015).  I didn't make a public announcement, and just 
got on and did a rewrite.  (-:


It is here, complete with SGML patch: 
https://jdebp.eu./Proposals/DebianPolicy/

Fixing the Debian Policy Manual to finally reflect changes from 2014 (was: "Is missing SysV-init support a bug?" on debian-devel)

[Jonathan de Boyne Pollard]

Robert Edmonds:


The relevant text from the policy manual, §9.11: [...]


Ansgar Burchardt:

Was that changed since the default init system was changed?  It pretty 
much still reads like Policy still assumes that sysvinit is the 
default init system.  It also still mentions upstart in 9.11.1; will 
file a bug for that. If it wasn't changed, just s/sysvinit/systemd/ 
mentally ;)  It's not the only place where Policy lags behind what is 
actual practice.


For your bug, please note that the grunt work of fixing Debian Policy 
has already been done long since, and a patch exists:


* https://jdebp.eu./Proposals/DebianPolicy/

Re: Is missing SysV-init support a bug?

[Bastian Blank]

On Fri, Aug 26, 2016 at 08:10:19PM +0500, Andrey Rahmatullin wrote:
> On Fri, Aug 26, 2016 at 02:26:53PM +0100, Ian Jackson wrote:
> > > The rationale for the change was:
> > >  * sysvinit conntrackd script is really poor, to reliably use
> > >conntrackd as a systemd daemon you should use systemd
> > There are no bugs about this at:
> >
> > https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=conntrackd;dist=unstable
> Because finding a bug would require actually using sysvinit.

Prove by proclamation.  So there is no problem at all.

Bastian

-- 
Not one hundred percent efficient, of course ... but nothing ever is.
-- Kirk, "Metamorphosis", stardate 3219.8

Re: libsystemd [was: Re: Is missing SysV-init support a bug?]

[Adam Borowski]

On Sat, Aug 27, 2016 at 10:33:36AM +0300, Dmitry Bogatov wrote:
> > > I hugely support idea of dynamically loading libsystemd.
> >
> > Please don't, no.  While I do think packages should keep sysvinit
> > support as long as it continues to work and doesn't make other paths
> > worse, I don't think it makes sense to omit linking to libsystemd, or to
> > dlopen it at runtime.
> 
> Extra useless dependency. This is case when I miss Gentoo's use-flags.

But _why_ would you want to avoid libsystemd?  Its only bad effect is
wasting a negligible amount of disk space and a few pages memory.  Do you
recompile for example clementine/amarok/rhythmbox/banshee without libgpod
just because you don't own such an ancient piece of iCrap?  Unless you go
really deeply embedded, fighting such slight bloat is not worth your time.

_This_ is bloat:
[41270.363188] Out of memory: Kill process 14533 (firefox) score 104 or 
sacrifice child
[41270.363362] Killed process 14533 (firefox) total-vm:3598348kB,
anon-rss:1695684kB, file-rss:46384kB, shmem-rss:26904kB
This is not:
Package: libsystemd0
Installed-Size: 635
Package: libgpod4
Installed-Size: 557
Even if libsystemd0 was completely loaded into memory, count how many orders
of magnitude less waste it would be than a browser.

> If I don't like libsystemd dependency, I am in much worse position,
> since I have to rebuild really a lot of packages. Yes, we have
> `angband.pl' repository, but this not systematic solution.

As I'm the guy behind that repository, my reason for recompiling everything
without libsystemd is not pruning this small dependency -- it's a cheap way
to ascertain programs use non-systemd code paths.  It'd be nice if all of
them did the detection at runtime, but unfortunately some (like policykit-1)
have mutually exclusive code paths that get chosen at compile time.  By
compiling with no systemd libraries, I can be sure all such pitfalls are
avoided.  But that's only a short-term gain.


Meow!
-- 
An imaginary friend squared is a real enemy.

Re: Is missing SysV-init support a bug?

[Bart Schouten]

Holger Levsen schreef op 26-08-2016 14:16:

So, obviously from my point of view, lack of sysvinit support is not a 
bug.


And policy supports your view, considering the above (*) are 
"compelling

reasons" to do so.

(*) and the fact that conntrackd is linux only…


Personally I do not run a non-SystemD system, it is just too hard, 
probably, too much work, currently.


Yet, I greatly benefit from the availability of the existence of SysV 
scripts, because they allow me to switch individual parts away from 
SystemD, even if it requires writing a simple SystemD service file to do 
that.


Then SystemD may think it controls my system all it wants. But it is 
still running my init V scripts that I can edit and control to my 
liking.


The only reason to remove those scripts is to force people not to use 
them anymore. There are no other "good" reasons.


Grub/SystemD maintainer Andrei Borkenzov once wrote that mr. Martin Pitt 
writing that people not wanting to use certain features could do so was 
rather disingenuous since e.g. SytemD 220 (or around) removed certain 
scripts from /lib/udev that were required for such functionaly (e.g. 
write_net_rules/rule_generator.functions).


Deleting such scripts just means burning bridges for people.

Re: libsystemd [was: Re: Is missing SysV-init support a bug?]

[Russ Allbery]

Dmitry Bogatov  writes:

> You convinced me. If I pursue simplicity, it would be better to just
> recompile packages to get rid of unwanted dependencies.

I strongly suspect the amount of time you have spent participating in this
thread already exceeds all benefit you will ever achieve from recompiling
things to remove small dependencies like libsystemd over your entire
lifetime.

Premature optimization is the root of all evil, to quote Knuth.

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

Re: libsystemd [was: Re: Is missing SysV-init support a bug?]

[Andrey Rahmatullin]

On Sat, Aug 27, 2016 at 07:36:02AM -0400, The Wanderer wrote:
> There is one minor/cosmetic downside of libsystemd as currently
> provided, however: the apt-listchanges changelog.
> 
> The only '*systemd*' package which I have installed is libsystemd0.
> However, whenever I dist-upgrade (which is at least weekly if not daily,
> against testing) and a new version of libsystemd0 gets installed,
> apt-listchanges shows me what appears to be the changelog for the
> systemd source package - which rarely (if ever) includes anything about
> changes which seem to relate to libsystemd0 itself, only to the larger
> suite of programs for which it serves as a stub layer.
This problem is not specific to libsystemd, of course.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: libsystemd [was: Re: Is missing SysV-init support a bug?]

[The Wanderer]

On 2016-08-27 at 06:26, Andrew Shadura wrote:

> On 27 August 2016 at 10:33, Dmitry Bogatov  wrote:
> 
>> Like compat package, which provides libsystemd.a static library
>> and headers, that mirrors interface of libsystemd. This library
>> would forward call to actual libsystemd, if it exists and return
>> error, if it does not.
>> 
>> Probably, this method can be used with other libraries, like
>> libaudit or libdbus.
> 
> You're going to be surprised to learn such library exists.
> 
> It is called libsystemd.

There is one minor/cosmetic downside of libsystemd as currently
provided, however: the apt-listchanges changelog.

The only '*systemd*' package which I have installed is libsystemd0.
However, whenever I dist-upgrade (which is at least weekly if not daily,
against testing) and a new version of libsystemd0 gets installed,
apt-listchanges shows me what appears to be the changelog for the
systemd source package - which rarely (if ever) includes anything about
changes which seem to relate to libsystemd0 itself, only to the larger
suite of programs for which it serves as a stub layer.

Having to wade through that frequently fairly large list, just on the
off-chance there's anything which will affect code that's actually being
changed on my system, is a pain.


(It's actually worse than that, because this would happen even if I also
removed libsystemd0; this same systemd-source-package(?) changelog
appears to be displayed on upgrades of _udev_, for no apparent reason
beyond udev now apparently(?) being maintained as part of that same
umbrella suite of software - and indeed, changes to udev _are_ sometimes
mentioned in the 'systemd' changelog and apparently are not mentioned
elsewhere, which means I do need to wade through that changelog in case
anything relevant is mentioned.

IMO this level of integration between things which are not mutually
interdependent is a minor bug in itself, but none of the maintainers are
going to agree with me on that.)

-- 
   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: libsystemd [was: Re: Is missing SysV-init support a bug?]

[Dmitry Bogatov]

> Once per thread about systemd, I point out that dbus-daemon links to both
> libapparmor and libselinux - which results in at least one useless library
> for literally everyone with dbus installed, since "major" LSMs don't
> stack, so nobody can possibly be using both AppArmor and SELinux at the same
> time. Oddly enough, nobody has complained about that, only about
> libsystemd...

Thanks for hint.

> In particular, changing programs to dlopen libsystemd is actively harmful -
> it is not just a waste of effort, it would also defeat Debian's
> deb-symbols(5) mechanism.

Agree.

> Now that we have versioned Provides, you could substitute a stub version
> of the shared libsystemd without recompiling *anything*, if it matters
> so much to you. Make sure to tell the libsystemd maintainers you have
> done so, so that they can make reportbug report whether the stub version
> is installed, and reassign all bug reports involving the stub version to
> be analyzed by its maintainer and minimize the amount of their time that
> is unnecessarily taken up by it.

Well, that wasn't my idea. But after some research I concluded, that
to implement this stub would require more job of understanding
library, then I expected.

> I honestly don't think this is a good idea even if you will never run
> systemd, though. One of the reasons that is frequently given for
> avoiding systemd is reducing the (perceived or real) complexity of the
> overall system... but every time there's a swappable component, that's
> an increase in complexity.

You convinced me. If I pursue simplicity, it would be better to just
recompile packages to get rid of unwanted dependencies.

Back to original topic -- dear maintainers, please do not (complicate
usage|make unusable) your packages on sysvinit systems.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Re: libsystemd [was: Re: Is missing SysV-init support a bug?]

[Simon McVittie]

On Sat, 27 Aug 2016 at 10:33:36 +0300, Dmitry Bogatov wrote:
> 
> > > >  * conntrackd & systemd are very good integrated (using libsystemd)
> > >
> > > I hugely support idea of dynamically loading libsystemd.
> >
> > Please don't, no.  While I do think packages should keep sysvinit
> > support as long as it continues to work and doesn't make other paths
> > worse, I don't think it makes sense to omit linking to libsystemd, or to
> > dlopen it at runtime.
> 
> Extra useless dependency. This is case when I miss Gentoo's use-flags.

Once per thread about systemd, I point out that dbus-daemon links to both
libapparmor and libselinux - which results in at least one useless library
for literally everyone with dbus installed, since "major" LSMs don't
stack, so nobody can possibly be using both AppArmor and SELinux at the same
time. Oddly enough, nobody has complained about that, only about
libsystemd...

This is the price you pay for using a binary distribution like Debian
(or Fedora, or SuSE, or Devuan, or whatever). I don't use SELinux,
but libselinux is pseudo-Essential, so I have to have it - and that's fine,
the engineering effort required to make it optional would "cost" more
than the disk space it takes up.

In particular, changing programs to dlopen libsystemd is actively harmful -
it is not just a waste of effort, it would also defeat Debian's
deb-symbols(5) mechanism.

> But I agree, that changing programs to dlopen libystemd is too much
> problem. Too much of them. But I think we can do better.
> 
> Like compat package, which provides libsystemd.a static library and
> headers, that mirrors interface of libsystemd. This library would
> forward call to actual libsystemd, if it exists and return error, if
> it does not.

You mean like libsystemd, which looks in /run to see whether systemd is in
use, talks to it if it is, and returns some suitable error code (-ENOSYS?)
if it isn't? :-)

Now that we have versioned Provides, you could substitute a stub version
of the shared libsystemd without recompiling *anything*, if it matters
so much to you. Make sure to tell the libsystemd maintainers you have
done so, so that they can make reportbug report whether the stub version
is installed, and reassign all bug reports involving the stub version to
be analyzed by its maintainer and minimize the amount of their time that
is unnecessarily taken up by it.

I honestly don't think this is a good idea even if you will never run
systemd, though. One of the reasons that is frequently given for
avoiding systemd is reducing the (perceived or real) complexity of the
overall system... but every time there's a swappable component, that's
an increase in complexity. The overall system consisting of libsystemd
and your stub/shim libsystemd is more complex for Debian to support,
with more things that can go wrong, than libsystemd itself.

S

Re: libsystemd [was: Re: Is missing SysV-init support a bug?]

[Andrey Rahmatullin]

On Sat, Aug 27, 2016 at 10:33:36AM +0300, Dmitry Bogatov wrote:
> > > I hugely support idea of dynamically loading libsystemd.
> >
> > Please don't, no.  While I do think packages should keep sysvinit
> > support as long as it continues to work and doesn't make other paths
> > worse, I don't think it makes sense to omit linking to libsystemd, or to
> > dlopen it at runtime.
> 
> Extra useless dependency. This is case when I miss Gentoo's use-flags.
> 
> We already have emacs24, which builds with support of everything,
> including tiff and dbus. If I do not like it, I have two option -- use
> emacs-nox (thanks to maintainer, who built it) or rebuild package
> locally.
> 
> If I don't like libsystemd dependency, I am in much worse position,
> since I have to rebuild really a lot of packages. Yes, we have
> `angband.pl' repository, but this not systematic solution.
You could switch to Devuan, they build packages without this useless
dependency.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: libsystemd [was: Re: Is missing SysV-init support a bug?]

[Dmitry Bogatov]

> > >  * conntrackd & systemd are very good integrated (using libsystemd)
> >
> > I hugely support idea of dynamically loading libsystemd.
>
> Please don't, no.  While I do think packages should keep sysvinit
> support as long as it continues to work and doesn't make other paths
> worse, I don't think it makes sense to omit linking to libsystemd, or to
> dlopen it at runtime.

Extra useless dependency. This is case when I miss Gentoo's use-flags.

We already have emacs24, which builds with support of everything,
including tiff and dbus. If I do not like it, I have two option -- use
emacs-nox (thanks to maintainer, who built it) or rebuild package
locally.

If I don't like libsystemd dependency, I am in much worse position,
since I have to rebuild really a lot of packages. Yes, we have
`angband.pl' repository, but this not systematic solution.

> Programs linked to libsystemd run just fine under sysvinit or any other
> init system.  Changing those programs to dlopen libsystemd does not seem
> worthwhile.

But I agree, that changing programs to dlopen libystemd is too much
problem. Too much of them. But I think we can do better.

Like compat package, which provides libsystemd.a static library and
headers, that mirrors interface of libsystemd. This library would
forward call to actual libsystemd, if it exists and return error, if
it does not.

Probably, this method can be used with other libraries, like libaudit
or libdbus.

No offence to anyone. Just like those, who does not use sysvinit want
to get rid of sysvinit-related stuff, I, who does not use systemd, try
to get rid of systemd-related stuff.

/away making experiments with it

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

libsystemd [was: Re: Is missing SysV-init support a bug?]

[Josh Triplett]

Dmitry Bogatov wrote:
> Arturo Borrero Gonzalez wrote:
> >  * conntrackd & systemd are very good integrated (using libsystemd)
> 
> I hugely support idea of dynamically loading libsystemd.

Please don't, no.  While I do think packages should keep sysvinit
support as long as it continues to work and doesn't make other paths
worse, I don't think it makes sense to omit linking to libsystemd, or to
dlopen it at runtime.

Programs linked to libsystemd run just fine under sysvinit or any other
init system.  Changing those programs to dlopen libsystemd does not seem
worthwhile.

Re: Is missing SysV-init support a bug?

[Attila Kinali]

On Thu, 25 Aug 2016 19:47:55 -0400
Robert Edmonds  wrote:

> I would guess that the vast majority of folks still using sysvinit with
> Debian are running wheezy or older, and thus removing sysvinit scripts
> from packages in unstable wouldn't affect them. But maybe that still
> leaves a reasonable number of testing/unstable + sysvinit users.

Not true. I know quite a few people running server systems, who stick
to sysV for simplicity reasons (having greater control over your system
is a big plus there). 

Attila Kinali

-- 
It is upon moral qualities that a society is ultimately founded. All 
the prosperity and technological sophistication in the world is of no 
use without that foundation.
 -- Miss Matheson, The Diamond Age, Neil Stephenson

Re: Is missing SysV-init support a bug?

[Adam D. Barratt]

On Fri, 2016-08-26 at 18:39 +0200, Christoph Anton Mitterer wrote:
> On Fri, 2016-08-26 at 17:07 +0100, Adam D. Barratt wrote:
> > No. It shows that, two years ago, over 18,000 machines that were 
> > reporting to the popcon servers had sysvinit-core installed and now
> > less 
> > than a third of that number do.
> 
> Still doesn't make it in any way representative...
> There could be only few submitters who run e.g. large cluster farms all
> with the same configuration.
> 
> Especially since popcon is an opt-in service it cannot be seriously
> used for any arguing IMHO.

You might want to consider actually reading the part of my post that you
snipped out, rather than reacting to what you appear to think I said:


(Whether those machines submitting popcon data are reprentative of the 
wider installed based is a different discussion.)


Regards,

Adam

Re: Is missing SysV-init support a bug?

[Wookey]

On 2016-08-25 19:47 -0400, Robert Edmonds wrote:
> Russ Allbery wrote:
> > Robert Edmonds  writes:

> I would guess that the vast majority of folks still using sysvinit with
> Debian are running wheezy or older, and thus removing sysvinit scripts
> from packages in unstable wouldn't affect them. But maybe that still
> leaves a reasonable number of testing/unstable + sysvinit users.

I'm using sysvinit+jessie on my main machine. I expect shortly to
become a sysvinit+testing user. So please don't just bin sysvinit
support if there already is some.

I do now also have a systemd+jessie machine, and having both is useful
for testing breakage (like the recent
schroot/systemd/private-mount-namespace thing I mailed about).

After Stretch there may not be that many sysvinit users, but I think
that 2 releases is the minimum sensible period to maintain support for
such a siginificant change.

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


signature.asc
Description: Digital signature