Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Tollef Fog Heen]

]] Russ Allbery 

(Cleaned up the Cc line somewhat)

> You can do quite a bit with the hooks that are part of the specification
> of both types of files.  For example, logic that you may add to control
> whether the service should start at all can be implemented by adding a
> pre-start stanza to the upstart configuration.

ExecStartPre=/bin/false

will make the service be considered failed.  The ExecStartPre line can
of course be an executable that implements more checking or logic.

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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/m2habydmmu@rahvafeir.err.no

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[John Paul Adrian Glaubitz]

On 10/31/2013 02:50 AM, Theodore Ts'o wrote:
> The most basic is the idea that whether you can control (via shell
> scrpit fragments) whether or not a service should start at all, and
> what options or environments should be enabled by pasing some file.
> The fact that we can put that sort of thing in configuration files
> such as /etc/default/*, for example.
> 
> Yes, yes, you can do this via if you use system V init scripts scripts
> in backwards compatibility mode, but you've argued that we should be
> moving briskly away from that.  In which case system administrators
> will need to hand-edit the services files by hand, which will no doubt
> increase the chances of conflicts at package upgrade time, compared to
> if the configuration options were isolated away in files such as
> /etc/default/rsync (for example).

Ted, I'm sorry, but it's very obvious you have no clue how systemd is
supposed to be used. First of all, systemd - like udevd - supports
two places where to place systemd service files. One is located
below /usr/lib/systemd which is the directory where service files
provided by the package are placed, and one is /etc/systemd where
your own, custom service files are located.

If systemd finds an appropriate service file in /etc/systemd it will
ignore the appropriate service file in /usr/lib/systemd, always. So
there is never a problem with service files being overwritten during an
upgrade like you describe.

The same holds true, btw, for udevd with it's rules files which are
located in /lib/udev/rules.d and /etc/rules.d respectively.

And everything that you might want change in the configuration of
a service can be done by editing the service file and this in
a much easier and consistent way. Editing a file in the .ini
file format is a no-brainer which, in the worst mistake case, will
probably lead to an error message from the daemon or systemd while
messed up custom code may end up rendering your whole system unusable
if you are smart enough to mess up an rm command. Just have a look
at this wonderful bug in upstart [1].

> If the package does not ship a SysV init script (which is your ideal
> long-term outcome), that may not be very practical option for a system
> adminsitrator who may need to recreate a SysV init script, especially
> if the service file is rather complicated, or is using some of the
> more advanced feature of systemd/upstart.

No, System V Init scripts are not ideal on the long-term outcome since
they are highly distribution-specific, error-prone and annoying to
maintain. We have had tons of bugs in the bug tracker because of
broken init scripts, like this one [2].

I don't understand why anyone would think that having to write a small
piece of code to start another program is a sensible and good design,
especially when this is done for dozens of programs (= daemons) in very
much the same way. It absolutely makes sense to encode the logic to
start and control a daemon through a single piece of C code rather
than writing more-or-less the same bash script for every
single daemon on your machine.

Adrian

> [1] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/557177
> [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668890

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5271ebb8.8040...@physik.fu-berlin.de

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Zbigniew Jędrzejewski-Szmek]

On Wed, Oct 30, 2013 at 09:50:53PM -0400, Theodore Ts'o wrote:
> On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:
> > I suspect you and I have a root disagreement over the utility of exposing
> > some of those degrees of freedom to every init script author, but if you
> > have some more specific examples of policy that you wanted to change but
> > couldn't, I'd be interested in examples.
> 
> It's not necessarily the init script author who might want the degrees
> of freedom, but the local system administrator.
> 
> The most basic is the idea that whether you can control (via shell
> scrpit fragments) whether or not a service should start at all, and
> what options or environments should be enabled by pasing some file.
> The fact that we can put that sort of thing in configuration files
> such as /etc/default/*, for example.
Both systemd and upstart support this well enough.

With systemd you can say EnvironmentFile=/etc/default/
and use the variables in ExecStart=/path/to/prog $VAR1 $VAR2.
This is usually discouraged, not because it doesn't work, but
because it uses two files to provide very little value. In majority
of cases it turns out that the settings in /etc/default either
can't be changed in an useful way, or are better read by the daemon
itself from a different configuration file. But if you want this, then
it's there.

If the settings are to complicated for the declarative style, you
can always use an helper shell script to launch the daemon.
Again, discouraged, but certainly supported.

> Yes, yes, you can do this via if you use system V init scripts scripts
> in backwards compatibility mode, but you've argued that we should be
> moving briskly away from that.  In which case system administrators
> will need to hand-edit the services files by hand, which will no doubt
> increase the chances of conflicts at package upgrade time, compared to
> if the configuration options were isolated away in files such as
> /etc/default/rsync (for example).
Actually this doesn't happen that often. Typical systemd service file
has 1-3 lines of documentation, 1+ lines of ExecStart stuff, and a few
additional settings. They are mostly orthogonal, so you just override
the one you need. Probably most common case is to override ExecStart=,
done by adding the file like /etc/systemd/system/myservice.d/custom-start.conf
which only overrides ExecStart. Nice and simple, no conflicts on upgrade.

> > I realize that
> > the local administrator may have other goals, and they should have ways of
> > achieving them, but both systemd and upstart support running SysV init
> > scripts for those cases.
> 
> If the package does not ship a SysV init script (which is your ideal
> long-term outcome), that may not be very practical option for a system
> adminsitrator who may need to recreate a SysV init script, especially
> if the service file is rather complicated, or is using some of the
> more advanced feature of systemd/upstart.
Why would you recreate the whole script? Let the init manager take
care of starting and stopping and supervising, and only do the custom
stuff in the script. Then it should be just a few lines.

Zbyszek


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131031022135.gs28...@in.waw.pl

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Russ Allbery]

Theodore Ts'o  writes:
> On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:

>> I suspect you and I have a root disagreement over the utility of
>> exposing some of those degrees of freedom to every init script author,
>> but if you have some more specific examples of policy that you wanted
>> to change but couldn't, I'd be interested in examples.

> It's not necessarily the init script author who might want the degrees
> of freedom, but the local system administrator.

> The most basic is the idea that whether you can control (via shell
> scrpit fragments) whether or not a service should start at all, and what
> options or environments should be enabled by pasing some file.  The fact
> that we can put that sort of thing in configuration files such as
> /etc/default/*, for example.

> Yes, yes, you can do this via if you use system V init scripts scripts
> in backwards compatibility mode, but you've argued that we should be
> moving briskly away from that.  In which case system administrators will
> need to hand-edit the services files by hand, which will no doubt
> increase the chances of conflicts at package upgrade time, compared to
> if the configuration options were isolated away in files such as
> /etc/default/rsync (for example).

Ah, I see.

However, I do think this is mostly a solvable problem.  We should provide
meaningful flexibility in our init script configuration, which may include
providing hooks so that local administrators have a place to put that
local policy.

You're right that some of this functionality will probably be lost in the
initial conversion to something other than init scripts, but I would
consider that to (usually) be a bug, and as people report problems, we can
be sure it's added back in after understanding the issues involved.  Yes,
this may be a bit annoying for people in the short term, but I do think it
gets us to a better place in the long run by way of supporting clean and
documented interfaces for those policy settings.

It is true that currently init scripts are full-blown programs, allowing
anyone who is capable of programming in that language to make arbitrary
policy modifications.  We lose that by switching to a higher-level
language, and only policy decisions anticipated by that language will be
easily implemented.  More complex policy decisions would have to be
handled at a higher level, via selectively creating or removing the
configuration files.  It's certainly a disruptive change.  I'm not
convinced it's a net negative, but it will depend on how strong the
available hooks are and what types of policy the local administrator wants
to easily change.

I do think that being able to treat the init scripts as real configuration
files will make maintaining such local policy easier than it is currently.
The prospect of modifying init scripts was already dire enough that we
pushed most meaningful configuration into /etc/default instead of asking
that people change the complicated init scripts and then handle merges on
package upgrades.  *Most* local changes are fairly simple, and would only
require small and mergable changes to upstart configuration files, and
small overrides to systemd files.

I personally like upstart's model a little better, but systemd's model of
/etc overrides /lib is, I think, workable as long as people remember to
change only the setting they want and then include the original instead of
making copies of the whole configuration.  (That being said, I'm worried
about how the systemd model handles the common case of wanting to change
the command-line arguments to a daemon, and then having the package also
change the command-line arguments in some orthogonal way.)

> If the package does not ship a SysV init script (which is your ideal
> long-term outcome), that may not be very practical option for a system
> adminsitrator who may need to recreate a SysV init script, especially if
> the service file is rather complicated, or is using some of the more
> advanced feature of systemd/upstart.

You can do quite a bit with the hooks that are part of the specification
of both types of files.  For example, logic that you may add to control
whether the service should start at all can be implemented by adding a
pre-start stanza to the upstart configuration.

This particular action appears to be harder to do in systemd, which
doesn't, at least from the documentation that I've found, support running
arbitrary shell code to determine whether to start a unit, but there are a
bunch of other possible built-in checks.  I suppose one could also change
the command started to wrap it and put the check there, although that
feels quite ugly.

In general, upstart's integration with arbitrary actions in shell
fragments is considerably better than systemd's, at least based on the
documentation I've read.  upstart feels like it provides more useful
flexibility.

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


-- 
To UNSUBSCRIBE, 

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Theodore Ts'o]

On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:
> I suspect you and I have a root disagreement over the utility of exposing
> some of those degrees of freedom to every init script author, but if you
> have some more specific examples of policy that you wanted to change but
> couldn't, I'd be interested in examples.

It's not necessarily the init script author who might want the degrees
of freedom, but the local system administrator.

The most basic is the idea that whether you can control (via shell
scrpit fragments) whether or not a service should start at all, and
what options or environments should be enabled by pasing some file.
The fact that we can put that sort of thing in configuration files
such as /etc/default/*, for example.

Yes, yes, you can do this via if you use system V init scripts scripts
in backwards compatibility mode, but you've argued that we should be
moving briskly away from that.  In which case system administrators
will need to hand-edit the services files by hand, which will no doubt
increase the chances of conflicts at package upgrade time, compared to
if the configuration options were isolated away in files such as
/etc/default/rsync (for example).

> I realize that
> the local administrator may have other goals, and they should have ways of
> achieving them, but both systemd and upstart support running SysV init
> scripts for those cases.

If the package does not ship a SysV init script (which is your ideal
long-term outcome), that may not be very practical option for a system
adminsitrator who may need to recreate a SysV init script, especially
if the service file is rather complicated, or is using some of the
more advanced feature of systemd/upstart.

- Ted


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131031015053.gb9...@thunk.org

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Theodore Ts'o]

On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote:
> Well, I've said this before, but I think it's worth reiterating.  Either
> upstart or systemd configurations are *radically better* than init scripts
> on basically every axis.  They're more robust, more maintainable, easier
> for the local administrator to fix and revise, better on package upgrades,
> support new capabilities, etc.

Can you please go in to more detail why you believe this was true?

The lsat time I played with Upstart, I saw a lot of policy moved from
shell scripts into C code (which I would have to edit and recompile)
if I wanted to change things.  I also was extremely frustrated with a
massive lack of documentation, where at least with shell scripts I
could read the scripts to understand what was going on.

Maybe things have changed, but that was my impression with both
Systemd and Upstart (and policykit, and consolekit, etc. all of which
has caused me no end of frustration).

- Ted


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131031004110.ga9...@thunk.org

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Russ Allbery]

Theodore Ts'o  writes:
> On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote:

>> Well, I've said this before, but I think it's worth reiterating.
>> Either upstart or systemd configurations are *radically better* than
>> init scripts on basically every axis.  They're more robust, more
>> maintainable, easier for the local administrator to fix and revise,
>> better on package upgrades, support new capabilities, etc.

> Can you please go in to more detail why you believe this was true?

I think it's painfully obvious if you compare an init script to an upstart
or systemd configuration file for a simple daemon like, say, my lbcd
package.

For those who don't agree, please try the exercise of writing systemd and
upstart configuration files for some typical daemon package and look at
the number of lines of code in both and the behavior in edge cases (daemon
already running, daemon running but with no PID file because something
else deleted it, daemon part of a dependency chain that shouldn't fire
until the daemon is actually listening to the network, correct exit status
for various failure conditions, stopping the daemon when there is a user
process with the same name as the daemon also running, and the other cases
Policy says one must handle).  Now compare the length of time it took you
to make an init script correctly handle all those cases versus how long it
took to write the upstart or systemd configuration.  (Note that I have
found, IIRC, two different edge-case bugs in /etc/init.d/skeleton while
working on Debian, so even if you start from that file, which is only
applicable to a relatively narrow range of circumstances, you can still
fail edge cases.)

I have prior experience here both as Policy editor dealing with the Policy
sections related to init scripts and as a Lintian maintainer dealing with
Lintian checks for init scripts.  Both of those experiences were, shall we
say, convincing.

Another way to look at this is that both upstart and systemd provide a
high-level programming language for writing init scripts.  Not only does
it implement a higher level of abstraction, it's also better-suited to the
problem space because it's declarative rather than imperative.  (systemd
somewhat more so than upstart, although that makes it somewhat more
awkward to use in cases where you really need to run some shell script on
various actions.)

As with any move to a higher-level programming interface, there are
drawbacks; if you really want to do your own memory management, you don't
get to any more.  And as with most moves to a higher-level programming
interface well-suited to the task at hand, the advantages outweigh the
drawbacks.  (And in this case, I'd go a step farther and say that I think
most of the drawbacks people cite around loss of flexibility are at least
arguably benefits.  The world would be a better place with fewer init
scripts doing weird and unexpected things to paper over bugs better fixed
somewhere else.)

This really shouldn't be a particularly controversial stance.  Ever since
Solaris SMF, various UNIX implementations have been abandoning traditional
init scripts for exactly these reasons.  I really don't think that all
those completely independent technical teams, which at this point include
most major Linux distributions (counting OpenRC as another higher-level
implementation), are all wrong.

This is an area of personal interest of mine.  I followed daemontools
development back when Dan Bernstein was tackling this same basic problem
in his distinctively radical way, and have subsequently been paying at
least casual attention to various different daemon management facilities
ever since.  A lot of people have tried to solve various aspects of the
problem that init scripts are actually horrible at what they do, and the
solutions have been slowly improving and becoming more and more robust.

AFS attempted to solve this problem all the way back in the 1980s.  Even
back then, it was obvious that init scripts were insufficiently powerful
to manage production services properly, hence the whole bosserver system
that persists in OpenAFS to this day and which, coming from MIT, you may
be familiar with.  Not that I would advocate use of bosserver for anything
other than AFS these days, as there are now lots of newer technologies
that have surpassed it, although (relatively) secure network management of
services is still an interesting feature.

> The lsat time I played with Upstart, I saw a lot of policy moved from
> shell scripts into C code (which I would have to edit and recompile) if
> I wanted to change things.  I also was extremely frustrated with a
> massive lack of documentation, where at least with shell scripts I could
> read the scripts to understand what was going on.

I suspect you and I have a root disagreement over the utility of exposing
some of those degrees of freedom to every init script author, but if you
have some more specific examples of policy that you wanted to chang

Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Zbigniew Jędrzejewski-Szmek]

On Wed, Oct 30, 2013 at 04:58:36PM +0100, Tollef Fog Heen wrote:
> ]] Wouter Verhelst 
> 
> > Yes, absense of documentation is common on Unix and Linux systems; but
> > no, I do not think that this is okay, or that we should in any way
> > encourage that sort of thing.
> 
> By absense of documentation, are you referring to the almost 10% of the
> source base that are comments or the 15% that is DocBook XML based
> documentation?  (Almost 14kLOC and almost 36kLOX, respectively.)
Actually, in this case more documentation is on the wiki, so not included
in those statistics :)

1. Multi-Seat on Linux
   http://www.freedesktop.org/wiki/Software/systemd/multiseat

2. logind D-Bus API Documentation
   http://www.freedesktop.org/wiki/Software/systemd/logind

3. Inhibitor Lock Developer Documentation
   http://www.freedesktop.org/wiki/Software/systemd/inhibit

(and the manpages actually generated from DocBook)
4. http://www.freedesktop.org/software/systemd/man/logind.conf.html
   http://www.freedesktop.org/software/systemd/man/pam_systemd.html
   http://www.freedesktop.org/software/systemd/man/systemd-logind.html

Yeah, the documentation could be more complete, but it's hardly "absent".

Zbyszek


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131030172021.gr28...@in.waw.pl

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Steve Langasek]

On Wed, Oct 30, 2013 at 04:29:24PM +0100, Wouter Verhelst wrote:
> While I agree with your point, it's pretty difficult to reimplement the
> "interesting" parts of systemd in other implementations of pid1 if
> whoever wrote the "interesting" parts does not document it, does not say
> what it's supposed to do, does not want to accept patches for things
> they're not interested in, and is by and large uninterested in anyone
> who prefers to use something else than whatever their kool-aid is.

> I'll grant that maybe logind provides interesting functionality which
> other projects might want to depend on, and that there's nothing wrong
> with that. The problem, however, is that the functionality is not
> defined: if I want to provide an alternative pid1 implementation, then
> the specifications are clear, and I should Just Do It (not that I'm
> going to muddle the waters even more by doing so, but you understand the
> point). If I want to provide an alternative implementation of logind,
> however, then the only spec out there is the logind code, which might
> change one day to the next just because the logind developer feels like it.

Are there things missing from
 from an
implementor's perspective?

For my part I regard this as a tempest in a teapot.  Lennart has been
effective at making people worry that not using systemd is too dangerous to
consider.  But Ubuntu has done just fine with splitting the dbus services
off of init up through systemd 204, and while we know there are some big
issues on the horizon with the cgroup manager and kdbus questions, these are
not settled matters across the Free Software ecosystem.  There are lots of
other people besides the upstart and Debian non-Linux-port community who
have reservations about the systemd gravity well, including anyone using
cgroups today on top of lxc or using the Google tools.

So I'm not going to give anyone a roadmap today for how these capabilities
will be made available in a non-systemd environment, because a lot of this
has to do with decisions that need to be made in the relevant wider
technical communities and have nothing to do with the init system per se.

-- 
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: Digital signature

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Игорь Пашев]

2013/10/30 Helmut Grohne :
> What is going to happen with non-Linux ports?

Debian is not Debian without non-Linux ports.

As for me, I think it is not very hard to maintain diffrent init
systems for different kernels.
Especially if Debian GNU/Linux get rid of sysvinit: writing systemd or upstrart
services is simple (as well as SMF).

Just one example from OSDyson (lighttpd):

1. dh-smf: http://cgit.osdyson.org/dh-smf.git
2. lighttpd depends on dh-smf for illumos kernel:
http://cgit.osdyson.org/lighttpd.git/tree/debian/control#n10
3. No changes in d/rules (!):
http://cgit.osdyson.org/lighttpd.git/tree/debian/rules
4. DH automatically peeks up dh_smf:
http://cgit.osdyson.org/debhelper.git/tree/dh?id=3769023faf4758f944e710480c43cda220821690#n524
5. dh_smf looks into this directory:
http://cgit.osdyson.org/lighttpd.git/tree/debian/lighttpd.smf
6. dh_installinit is no-op on Dyson


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/call-q8zvzx9lr74v6erazu6dgj8ez6kvyigzswq+v77fbwr...@mail.gmail.com

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Tollef Fog Heen]

]] Wouter Verhelst 

> Yes, absense of documentation is common on Unix and Linux systems; but
> no, I do not think that this is okay, or that we should in any way
> encourage that sort of thing.

By absense of documentation, are you referring to the almost 10% of the
source base that are comments or the 15% that is DocBook XML based
documentation?  (Almost 14kLOC and almost 36kLOX, respectively.)

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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/m21u32g383@rahvafeir.err.no

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Zbigniew Jędrzejewski-Szmek]

On Wed, Oct 30, 2013 at 03:10:16PM +0100, Helmut Grohne wrote:
> The interfaces of all init systems (except sysvinit, but are we really
> considering that one?) still are somewhat in flux, so this is the point
> where we can still influence and shape them.
> 
> 
> Imagine a world where upstart and systemd would use the same syntax
> (structure) but implement different and somewhat overlapping aspects.
> Maybe 50% of the daemons would work with either of them without needing
> changes.  But now we call it "exec" here and "ExecStart" there,
> "export" here and "Environment" there, and "chdir" here and
> "WorkingDirectory" there. Bummer.
> 
Hi Helmut,
"exec" vs. "ExecStart=" and "export" vs. "Environment=" is easy.
Anyone can whip up a sed script to convert between those. The question
is how to deal with more advanced options. Let's say that I have a
systemd unit with

CapabilityBoundingSet=CAP_SYS_TIME# limit the capability bounding set to 
CAP_SYS_TIME
PrivateTmp=yes# run with unshared /tmp
InaccessibleDirectories=/home # run without access to /home
WatchdogSec=60# consider the service dead if it hasn't 
pinged the
  # manager for in the last minute
Restart=on-failure# restart service on watchdog failure or 
unclean exit

This isn't a question of syntax, it's a question of significant
functionality in the manager. I think that sharing service
descriptions between disparate init managers is infeasible, unless we
forbid the use of anything but the basic features.

Another thing that is turning into a significant gap is socket
activation.  In systemd, socket activation allows the service to
receive multiple open sockets (e.g. ports 80 and 443 for an httpd
server). Socket activation of daemons is cool:
- it is very easy to write such a daemon, it must just do accept(), read() and 
write()
- resource efficent because of activation on demand
- great for running unpriviledged, since the daemon only does accept(), read() 
and write()
- we get rid of a lot of inter-daemon ordering dependencies.
With the recent addition of (experimental) systemd-socket-proxyd[1],
even daemons like apache which do not support socket activation
internally can be launched on demand by wrapping them with a
helper. Socket activation is a great technique, bound to be used more.
Achieving the same functionality with init scripts is very
hard, and AFAIK, upstart doesn't support socket activation with
more than one socket.

[1] http://www.freedesktop.org/software/systemd/man/systemd-socket-proxyd.html

> Oh wait, I am talking to one of the guys who can actually fix this. :)

Zbyszek


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131030145246.gq28...@in.waw.pl

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Wouter Verhelst]

Op 30-10-13 00:16, Russ Allbery schreef:
> Carlos Alberto Lopez Perez  writes:
>> On 28/10/13 20:14, Christoph Anton Mitterer wrote:
> 
>>> For those who haven't seen it, Lennart has posted some of his comments
>>> about all this on G+:
>>> https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf
> 
>> And here is the reply from Gentoo developer Patrick Lauer:
> 
>> http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-29T13_39_32.txt
> 
> This, sadly, was not particularly useful or interesting.

I disagree. His point isn't argued very well (seems more like a rant
than a discussion), but it's there.

> As near as I can
> tell, the core content was that he doesn't think cgroup management is
> particularly difficult (fine, but I don't think that was the point; the
> point, instead, was that it's important to have a single arbitrator, which
> if true poses specific technical challenges) and he believes that the
> components to systemd would be easy to implement as separate daemons if
> they were properly documented.
> 
> I'm one of those people who thinks that nearly everything in Linux is
> horribly underdocumented, so I'm not going to argue with that point, but
> it's not a very useful statement from a practical viewpoint.  systemd
> offers specific pieces of integrated functionality.  By and large, no one
> seems to question that the operations enabled by that functionality are
> useful (although there is some debate over how useful).  GNOME is not
> depending on systemd out of some nefarious plot.  It's depending on
> systemd because GNOME wants to use those pieces of functionality systemd
> provides.
> 
> Therefore, I think it's important for arguments against using systemd to
> somehow engage directly with the questions about functionality.  Either
> there needs to be an argument that the functionality is not important and
> can be done without (which raises questions about how one would build
> GNOME in such an environment), or there needs to be some sort of plan for
> how equivalent functionality to systemd will be provided.

>From the above link:

"The only thing stopping me from reimplementing that functionality is
that I have no idea what it's supposed to *do* ... and I don't enjoy
reading through all of systemd to find out."

(about logind)

While I agree with your point, it's pretty difficult to reimplement the
"interesting" parts of systemd in other implementations of pid1 if
whoever wrote the "interesting" parts does not document it, does not say
what it's supposed to do, does not want to accept patches for things
they're not interested in, and is by and large uninterested in anyone
who prefers to use something else than whatever their kool-aid is.

I'll grant that maybe logind provides interesting functionality which
other projects might want to depend on, and that there's nothing wrong
with that. The problem, however, is that the functionality is not
defined: if I want to provide an alternative pid1 implementation, then
the specifications are clear, and I should Just Do It (not that I'm
going to muddle the waters even more by doing so, but you understand the
point). If I want to provide an alternative implementation of logind,
however, then the only spec out there is the logind code, which might
change one day to the next just because the logind developer feels like it.

This wouldn't be much of a problem if I could just take logind (and
udev, and dbus, and more things) out of the systemd source tree and use
it without systemd, should I want to. But you can't; the problem is that
the upstream of all these projects is by and large uninterested in doing
so, and also does not seem to support other people who are, and at least
the Debian maintainers of systemd have gone on record as saying that
they won't guarantee this would remain possible (if the systemd
developers would be willing to do so, then I suppose that could
ameliorate some concerns).

The "obvious" solution would be that the world changes to systemd
because what, essentially, amounts to a level of sabotage by the systemd
developers of things that aren't systemd. If systemd is in fact the best
choice "out there", of which I'm not convinced at this point in time,
then I wouldn't mind that (much). But I'd like us to do so for the right
technical reasons, not just because it means we make our lives easier in
not having to fight with a stubborn upstream all the time. We could,
after all, fork, like we have done on other occasions of stubborn upstreams.

Given all of the above, I would even argue that perhaps Debian should
*not* adopt systemd as init system, out of principle; if we were to do
so, then almost all the major distributions would be using systemd (with
the sole exception of Ubuntu; I expect redhat to switch to systemd for
their next EL version), which could go a long way to making it part of
what it means to be running "Linux". At that point, any competing
innovative implementations would simpl

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Helmut Grohne]

Hi Steve,

On Tue, Oct 29, 2013 at 09:31:37AM -0700, Steve Langasek wrote:
> On Tue, Oct 29, 2013 at 10:22:54AM +0100, Helmut Grohne wrote:
> > Having read the parts of the ctte bug, it feels odd to preclude the
> > option of supporting multiple init systems from discussion or
> > consideration. If Debian is to support only one init system and that one
> > init system is systemd, then given my above analysis it will be very
> > hard for non-Linux ports to catch up. I argue that in this case we
> > should consider dropping support for non-Linux ports. So if we really
> > are considering such an outcome, why not consider the outcome of
> > supporting multiple init systems (but maybe only one per architecture)?
> 
> While other members of the TC may wish to consider this option, I've ruled
> it out myself because we would lose most of the benefits of switching away
> from sysvinit and instead accrue significant maintenance costs to individual
> developers who would then have to support both init systems in their
> packages.  What makes switching init systems worth doing is being able to
> *simplify* the interfaces between the init system and the services.
> Continuing to support different init systems across different architectures
> would add complexity instead.  That's a pretty bleak outcome.

I fully agree with your reasoning. Yet, I see that the options
 * drop support for non-Linux ports and
 * maintain some support for an alternate init system
are similarly painful. I see neither of them a desirable, but if we
really consider one of them, I'd ask for the other one to be considered
and evaluated as well.

Most participants in this thread appear to agree that the sysvinit
*interface* for services (shell scripts) is suboptimal. We are currently
mostly arguing about implementations, because each proposed interface
has only one implementation. It might make sense to consider a subset of
the interface that one implementation provides as our standard and
provide a degraded experience to that interface on non-Linux ports. For
example, if systemd were to be the init system of choice, it could be
required to provide an init script for services with Type=notify.

The interfaces of all init systems (except sysvinit, but are we really
considering that one?) still are somewhat in flux, so this is the point
where we can still influence and shape them.


Imagine a world where upstart and systemd would use the same syntax
(structure) but implement different and somewhat overlapping aspects.
Maybe 50% of the daemons would work with either of them without needing
changes.  But now we call it "exec" here and "ExecStart" there,
"export" here and "Environment" there, and "chdir" here and
"WorkingDirectory" there. Bummer.


Oh wait, I am talking to one of the guys who can actually fix this. :)

> > This would become radically easier if gnome were to become Architecture:
> > linux-any.
> 
> GNOME may be the trigger for this being raised to the TC, but it's not the
> core question that we need to address.

Even though I did mention gnome over there, the argument is not
restricted to gnome in any way. It can be applied to any other package
not deemed worthy to support on non-Linux ports (and I should have made
this explicit). Furthering this thought leads to turning non-Linux ports
into derivatives as presented by others in this thread.

I argue that a resolution of this bug needs to answer:

  What is going to happen with non-Linux ports?

Helmut


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131030141015.ga15...@alf.mars

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Wouter Verhelst]

Op 29-10-13 09:26, Steve Langasek schreef:
> I see no reason that, if upstart were chosen as the default, porters could
> not use it for our non-Linux ports as well.

With some work, sure.

> This is a much better outcome
> across our distribution as a whole than to require developers to continue
> maintaining init scripts just for our non-Linux ports.

I did not say "require", I said "encourage". I agree that it's
unreasonable to expect developers to maintain init scripts that they
themselves do not use in addition to init configuration for whatever
init system we end up with; and I do agree that it should be fair game
for people to drop the init script from their package.

However, there are some advantages to be had in continue to ship init
scripts (while I can see no downsides, apart from the fact that they
need to be written), and in that light it can make sense for us to
encourage people to continue shipping init scripts.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/



signature.asc
Description: OpenPGP digital signature

Bug#727708: Strong argument for OpenRC

[Thomas Goirand]

Hi,

I got a *new* argument in the favor of OpenRC:

http://youtu.be/zoNoi8BgQjs

Yes, we made it work in Debian GNU/kFreeBSD! :)

Upstream was very friendly helping to do this last night and this
morning. Now, the next blocker would be renaming /sbin/rc to
/sbin/openrc, though upstream pretends it shouldn't be hard to do, and
they told me they will work on it. I unfortunately (and of course, I'd
say) can't upload to Debian until this is fixed, though it's in
collab-maint for those who want to try.

I warmly welcome Hurd folks to try porting it too.

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5270babd.9030...@debian.org