Two line init.d scripts? Sure, that will work!

[Petter Reinholdtsen]

[Thomas Goirand]

Yeah, I discovered that OpenRC had a similar approach, but without
staying compatible with our current set of scripts in /etc/init.d/.

[1] Sorry... what?!? :)
It's perfectly compatible. You just decide what you want to
(re-)implement or not. In fact, that's one of the very strong point of
OpenRC: it allows a very smooth migration away from sysv-rc, where one
can decide what to re-write or not.

I realise I was a bit unclear. I mean that openrc scripts can not be
used with sysv-rc and file-rc (or systemd or upstart), not that openrc
is unable to handle LSB compatible init.d scripts. So a package
providing a openrc script will not be started on a system using
sysv-rc, if I understand it correctly. Did I misundertand this? I
realise openrc can handle all the existing init.d scripts with LSB
headers just fine.

Since last summer, OpenRC has full support for LSB headers. Also, I
believe that OpenRC is the only init system replacement which allows
to mix dependencies with LSB or it's own implementation.

That is not the case. Both systemd and upstart allow this as well.

This approach also make it easier to identify the "simple" init.d
scripts, and possibly also make it easier to integrate them with for
example systemd and upstart by providing a replacement for the
init-d-script script or by extending init-d-script.

Unfortunately, it doesn't, because there will be problems with
dependencies, as much as I understand.

Yes, different name spaces will be a challenge. But it can be handled
by deciding to keep the name spaces in sync, using the same name for
the same service in LSB headers, upstart jobs and systemd jobs.

--
Happy hacking
Petter Reinholdtsen

[Tollef Fog Heen]

]] Thomas Goirand

Since last summer, OpenRC has full support for LSB headers. Also, I
believe that OpenRC is the only init system replacement which allows to
mix dependencies with LSB or it's own implementation.

It's not, systemd has provided this from the start.

[Tollef Fog Heen]

]] Petter Reinholdtsen

Post by Petter Reinholdtsen

Since last summer, OpenRC has full support for LSB headers. Also, I
believe that OpenRC is the only init system replacement which allows
to mix dependencies with LSB or it's own implementation.

That is not the case. Both systemd and upstart allow this as well.

How do I write an upstart job that depends on a sysvinit service being
started (which again depends on a specific upstart job being started)?
IIRC, that's not supported, since init scripts aren't first class
citizens in upstart. That might have changed since last time I looked
at upstart, though.

Post by Petter Reinholdtsen
Yes, different name spaces will be a challenge. But it can be handled
by deciding to keep the name spaces in sync, using the same name for
the same service in LSB headers, upstart jobs and systemd jobs.

That + alias support. Anything else is not going to work.

[Petter Reinholdtsen]

[Thomas Goirand]

Well, you've been trying to reimplement OpenRC... with less
features! Don't bother, switch to OpenRC, and call it a day... :)

Actually, I am trying to reduce code duplication in /etc/init.d/ while
allowing package maintainers an easy way to stay compatible with
systemd, upstart, openrc, sysv-rc and file-rc, which to me is a
different problem than OpenRC try to solve. :)

Those that want to keep their current init.d script can do so without
any problems from this new approach whatsoever, so this is just an
option for those that want to move the task of writing init.d scripts
to me (or the ones maintaining init-d-script) instead of keeping it
for themselves. :)

By the way, I forgot to mention: the shebang thing replacement was
painful in OpenRC, so we recently made it so that we don't need to
replace it by /bin/openrc-run (previously called "runscripts")... :)

Where can I read more about these problems. One obvious and annoying
one is that 'sh -x /etc/init.d/script start' no longer work, making it
harder to debug the scripts, but that is the only one I have seen so
far.

[Sergey B Kirpichev]

Post by Petter Reinholdtsen
Where can I read more about these problems. One obvious and annoying
one is that 'sh -x /etc/init.d/script start' no longer work, making it
harder to debug the scripts

Probably init-d-script could pass some cli-specified options to sh
with set builtin. To allow something like this:

/etc/init.d/script -x start
or
/etc/init.d/script start -x

[Petter Reinholdtsen]

[Sergey B Kirpichev]

Post by Sergey B Kirpichev
Probably init-d-script could pass some cli-specified options to sh
/etc/init.d/script -x start
or
/etc/init.d/script start -x

I ended up with this instead: 'DEBUG=true /etc/init.d/script start'

The new /lib/init/init-d/script is in the sysvinit-utils package in
experimental now. Please check it out and see if it will work for your
init.d script. :)

[Petter Reinholdtsen]

[Sergey B Kirpichev]

Peter, thank you for your work. Have you tried any complex init
script to fit this business (apache2 or postfix, for example)?

Nope. It is ment as an option for the packages with simple needs.
Those with complex needs can use it too, probably, but it might be
easier to just keep the current init.d scripts.

BTW, I don't think your postfix script is an actual replacement for
the current init-script. For example, there are create_xconsole()
and sendsigs_omit() functions.

Ah, good point. Added do_start_cleanup and do_stop_prepare hooks to
cater for such needs.

Also, there is the do_rotate function - a very common example when
you want to implement a custom action (not just one from fixed set
start/stop/reload/etc).

Not quite sure if that is within scope of this mechanism. Will think
more about it.

https://lists.debian.org/debian-ctte/2013/12/msg00156.html

Multiple daemons is definitely out of scope.

Last but not least, we can utilize custom lsb-headers (X-Debian-*
like) to keep information like pidfile or daemon binary path name.
I think, there is a parser for this LSB-info somewhere in the lsb-*
packages.

Why do you believe this is an advantage?

PS: Peter Reinholdtsen is my distant cousin.

[Sergey B Kirpichev]

Post by Petter Reinholdtsen

Peter, thank you for your work. Have you tried any complex init
script to fit this business (apache2 or postfix, for example)?

Nope. It is ment as an option for the packages with simple needs.
Those with complex needs can use it too, probably, but it might be
easier to just keep the current init.d scripts.

They aren't too complex, actually.

Post by Petter Reinholdtsen
Ah, good point. Added do_start_cleanup and do_stop_prepare hooks to
cater for such needs.

Probably, we should have hooks,
that can be invoked before specified action (e.g. start or stop)
and after. But not just for start/stop.

BTW, there is try-restart action, mentioned in the LSB. Probably,
you should add this. And you can implement some standard
do_reload function (with HUP signal), disabled by
default; the package maintainer can enable this with one-liner like
alias do_reload_override=standard_boilerplate_for_do_reload

Also, a very common pattern is to specify some daemon
options somewhere in /etc/default/. Probably, it's a good
idea to include /etc/default/$YOUNAMEIT file and use
some variable (e.g. $OPTIONS) to provide additional
arguments to do_start_cmd/do_restart_cmd/do_reload_cmd.

Post by Petter Reinholdtsen

Also, there is the do_rotate function - a very common example when
you want to implement a custom action (not just one from fixed set
start/stop/reload/etc).

Not quite sure if that is within scope of this mechanism. Will think
more about it.

You can add a specific helper to be invoked if a non-standard
action is specified. Only if that helper doesn't exist
OR fail with status code 3 - call usage(). Then exit with the
provided status code (or 3).

Post by Petter Reinholdtsen
Multiple daemons is definitely out of scope.

I don't think that it's a bad idea to think about.

Post by Petter Reinholdtsen
PS: Peter Reinholdtsen is my distant cousin.

Sorry for typo :(

[Petter Reinholdtsen]

[Sergey B Kirpichev]

Post by Sergey B Kirpichev
They aren't too complex, actually.

Good. Perhaps someone got time to test if their content can be easily
transformed into init-d-script users. :)

Post by Sergey B Kirpichev
Probably, we should have hooks, that can be invoked before specified
action (e.g. start or stop) and after. But not just for start/stop.

I already got most of these hooks. Are more needed?

Post by Sergey B Kirpichev
BTW, there is try-restart action, mentioned in the LSB. Probably,
you should add this. And you can implement some standard
do_reload function (with HUP signal), disabled by
default; the package maintainer can enable this with one-liner like
alias do_reload_override=standard_boilerplate_for_do_reload

Good idea. Implemented.

Post by Sergey B Kirpichev
Also, a very common pattern is to specify some daemon
options somewhere in /etc/default/. Probably, it's a good
idea to include /etc/default/$YOUNAMEIT file and use
some variable (e.g. $OPTIONS) to provide additional
arguments to do_start_cmd/do_restart_cmd/do_reload_cmd.

This can be done by the init.d script itself by simply sourcing that
file. No need to do it in init-d-script.

Post by Sergey B Kirpichev
You can add a specific helper to be invoked if a non-standard action
is specified. Only if that helper doesn't exist OR fail with status
code 3 - call usage(). Then exit with the provided status code (or
3).

Good idea. Implemented.

Please check out the latest version.

Post by Sergey B Kirpichev
I don't think that it's a bad idea to think about.

Sure. Just trying to keep this mechanism simple. :)

Post by Sergey B Kirpichev
Sorry for typo :(

No problem. :)

[Sergey B Kirpichev]

Post by Petter Reinholdtsen

Post by Sergey B Kirpichev
Probably, we should have hooks, that can be invoked before specified
action (e.g. start or stop) and after. But not just for start/stop.

I already got most of these hooks. Are more needed?

I think, for every action, mentioned in the LSB. But
that's a minor issue.

Post by Petter Reinholdtsen

Post by Sergey B Kirpichev
BTW, there is try-restart action, mentioned in the LSB. Probably,
you should add this. And you can implement some standard
do_reload function (with HUP signal), disabled by
default; the package maintainer can enable this with one-liner like
alias do_reload_override=standard_boilerplate_for_do_reload

Good idea. Implemented.

I'm not sure if this is a right interface.

Post by Petter Reinholdtsen

Post by Sergey B Kirpichev
Also, a very common pattern is to specify some daemon
options somewhere in /etc/default/. Probably, it's a good
idea to include /etc/default/$YOUNAMEIT file and use
some variable (e.g. $OPTIONS) to provide additional
arguments to do_start_cmd/do_restart_cmd/do_reload_cmd.

This can be done by the init.d script itself by simply sourcing that
file. No need to do it in init-d-script.

Yes, but that's a *very* common pattern. Even for simple packages
(like monit) we must overload most of actions just for this reason.

So, I think it's reasonable to source /etc/defaults/ *or* to
use some specific shell variables to provide this flexibility.

Post by Petter Reinholdtsen

Post by Sergey B Kirpichev
You can add a specific helper to be invoked if a non-standard action
is specified. Only if that helper doesn't exist OR fail with status
code 3 - call usage(). Then exit with the provided status code (or
3).

Good idea. Implemented.
Please check out the latest version.

Ah. In this case, we probably want to overload (or, better, to
extend?) do_usage() as well.

[Ian Jackson]

A few months ago I drafted an idea to rewrite init.d scripts to use a
common implementation and only specify the unique parts in the init.d
scripts themselves. That draft can be found on
<URL: http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html >.

Before you go too far down this path, I'd like to suggest that you do
something which makes it possible to provide init system configuration
for other than sysvinit, at the same time. And that you use an
arrangement which uses a non-forking startup protocol for the daemon.

I think the best approach would probably be to automate the generation
of init scripts in debhelper.

Ian.

[Francesco P. Lovergine]

Post by Ian Jackson
I think the best approach would probably be to automate the generation
of init scripts in debhelper.

Seconded. Using an auto-generated skeleton starting from a simple template
would be more than enough to solve the main problem i.e. simplify maintainer
life.

[Gergely Nagy]

Post by Francesco P. Lovergine

Post by Ian Jackson
I think the best approach would probably be to automate the generation
of init scripts in debhelper.

Seconded. Using an auto-generated skeleton starting from a simple template
would be more than enough to solve the main problem i.e. simplify maintainer
life.

No, it would be a terrible idea: First, to reliably support all of the
init systems, you'd have to target the dumbest one, and either not
support the features of the others, or emulate them to some extent
within generated code.

Not supporting features of modern init systems means that the generator
is completely useless.

Trying to emulate features of the other init systems means you'll have
quite a bit of complexity and strange behaviour. That's not going to
simplify anyone's life, quite the contrary: it will make debugging
orders of magnitude harder, because you will now need to debug not only
the init script and the software itself, but the generator too. No,
thanks.

If you want to properly support multiple init systems, write the init
scripts / service files / etc for each of them. Anything else is going
to cause more trouble than what it is worth. The effort spent on trying
to come up with a way to generate init scripts from sources is better
spent creating systemd/openrc init files for software that don't have it
yet. If half the people campaigning for a generator would have written
one init script or service file a week, we'd have most things covered by
now.

[Petter Reinholdtsen]

[Gergely Nagy]

Post by Gergely Nagy
No, it would be a terrible idea: First, to reliably support all of the
init systems, you'd have to target the dumbest one, and either not
support the features of the others, or emulate them to some extent
within generated code.
Not supporting features of modern init systems means that the generator
is completely useless.

Your assumption is wrong. Most packages among the approximately 1000
packages with init.d scripts today have very simple needs. They need
to start, stop and restart one daemon. For these around 900 packages
(the remaining 100 start early in the boot and have more complex
needs), a generator would be very useful. :)

This is based on my experience when I went through most of the 1000
packages with init.d scripts to get them to include LSB style
dependency information.

For the remaining 100 or so packages, I expect hand written boot
scripts for each individual boot system is needed.

[Tollef Fog Heen]

]] Petter Reinholdtsen

Post by Petter Reinholdtsen
[Gergely Nagy]

Post by Gergely Nagy
No, it would be a terrible idea: First, to reliably support all of the
init systems, you'd have to target the dumbest one, and either not
support the features of the others, or emulate them to some extent
within generated code.
Not supporting features of modern init systems means that the generator
is completely useless.

Your assumption is wrong. Most packages among the approximately 1000
packages with init.d scripts today have very simple needs. They need
to start, stop and restart one daemon. For these around 900 packages
(the remaining 100 start early in the boot and have more complex
needs), a generator would be very useful. :)

I think many of them would be able to take advantage of features such as
private /tmp, private network namespaces, capability bounding sets,
limitation of new privileges and syscall filters.

Being able to start a daemon is necessary, but not sufficient for great
integration. I think we should aim for great, not the bare minimum.

[Matthias Urlichs]

Hi,

Post by Gergely Nagy
If you want to properly support multiple init systems, write the init
scripts / service files / etc for each of them.

The problem is that we all did that once already, and look where *that*
effort ended up: For sysv-rc, 1000 people copied (old versions of)
/etc/init.d/skeleton, hacked their daemon parameters into the variables in
the header, *maybe* checked that SIGHUP actually causes the thing to
re-read its configuration (if any) as opposed to exiting unglamosourly,
and hoped that it'd work.

Oh except that some people didn't, which causes problems for the systemd
transition -- because init skript that are not skeleton-based don't know
how to redirect itself to systemd 


I'd much rather have something well-tested and upgradeable which takes the
five lines you actually need for the common case(!) from a working systemd
service file and produces a sensible init script from that.

[Gergely Nagy]

Post by Matthias Urlichs
Oh except that some people didn't, which causes problems for the systemd
transition -- because init skript that are not skeleton-based don't know
how to redirect itself to systemd …

Err, no. I have plenty of sysvinit scripts that work just fine with
systemd, and are not at all based on skeleton.

Post by Matthias Urlichs
I'd much rather have something well-tested and upgradeable which takes the
five lines you actually need for the common case(!) from a working systemd
service file and produces a sensible init script from that.

I'd much rather support one init system that works instead of trying to
find workarounds for something that ended up being terrible.

Even if you generate an init script from systemd service files, the end
result will be terrible, on the same level as the current sysvinit
situation is. There's a reason it has not been done neither for upstart,
nor for systemd: it's not worth it.

[Matthias Urlichs]

Hi,

Post by Gergely Nagy

Post by Matthias Urlichs
Oh except that some people didn't, which causes problems for the systemd
transition -- because init skript that are not skeleton-based don't know
how to redirect itself to systemd 


Err, no. I have plenty of sysvinit scripts that work just fine with
systemd, and are not at all based on skeleton.

Note I said "redirect to systemd", not just "works with systemd".

Or s#based on skeleton#uses /lib/lsb/init-functions# if you did not miss that.

Post by Gergely Nagy
Even if you generate an init script from systemd service files, the end
result will be terrible, on the same level as the current sysvinit
situation is.

The result will either be exactly equivalent to a mostly-unmodified
skeleton script, which in many cases is an improvement, or die because of
unsupported service file stanzas.

In any case, I'd rather have an autogenerated init script and an uptodate
service file, than a somewhat-out-of-date sysvrc script which systemd runs
in compatibility mode and no systemd service file.

I'd like the common maintainer of the common daemon-providing package to be
able to get by with maintaining _one_ config file for said daemon which
s|he can actually test 


Finally, we don't *know* that

Post by Gergely Nagy
the end result will be terrible

unless somebody actually tries to do this.

Post by Gergely Nagy
There's a reason it has not been done neither for upstart,
nor for systemd: it's not worth it.

systemd is already declarative and runs sysv-rc scripts, so the cases are
not equivalent.

[Helmut Grohne]

Post by Ian Jackson
Before you go too far down this path, I'd like to suggest that you do
something which makes it possible to provide init system configuration
for other than sysvinit, at the same time. And that you use an
arrangement which uses a non-forking startup protocol for the daemon.
I think the best approach would probably be to automate the generation
of init scripts in debhelper.

Is that a joke? I find it hard to tell.

1) https://xkcd.com/927/ (we already had this here, why is it necessary
to reiterate?)

2) metainit (+ dh-metainit)! You don't have to work from scratch. All
you need to do, is pick up where Joachim Breitner stopped.

But I seriously doubt that this will get us very far, cause every time
someone suggested writing a tool for generating init scripts, the
discussion (and implementation) died once someone mentioned metainit. Do
we never learn from history?

Helmut

[Ian Jackson]

Post by Helmut Grohne

Post by Ian Jackson
I think the best approach would probably be to automate the generation
of init scripts in debhelper.

Is that a joke? I find it hard to tell.

I wasn't aware of metainit.

Post by Helmut Grohne
1) https://xkcd.com/927/ (we already had this here, why is it necessary
to reiterate?)
2) metainit (+ dh-metainit)! You don't have to work from scratch. All
you need to do, is pick up where Joachim Breitner stopped.
But I seriously doubt that this will get us very far, cause every time
someone suggested writing a tool for generating init scripts, the
discussion (and implementation) died once someone mentioned metainit. Do
we never learn from history?

I will look at metainit and see what I think.

Ian.

[Helmut Grohne]

Hi Ansgar,

I am sorry to tell you that you are completely missing the point.

The relevant bits can be found in insserv, watch out for
"/lib/init/upstart-job".

The current version of insserv in unstable, 1.14.0-5, doesn't seem to
contain this file.

insserv does not provide the upstart-job wrapper, but it supports(!) it
in being able to parse generated dependencies rather than reading the
init script.

My attempt to reproduce such a utility for systemd have not worked out
unfortunately (for lack of time/interest).

Using systemd jobs instead of the init script if available is already
~ # /etc/init.d/cron restart
[ ok ] Restarting cron (via systemctl): cron.service.

This functionality is entirely orthogonal to the one I was proposing.
You are talking about redirecting the init script invocation to a
running systemd instance. I am talking about sysvinit (as pid 1) to
execute systemd .service descriptions.

How would the init script continue to work on sysvinit if it was
replaced with a symlink as you said earlier?

When you invoke /etc/init.d/foo you really invoke the helper (e.g.
/lib/init/upstart-job). This helper evalutes its argv and determines,
that it is acting for service foo and what action to carry out. It then
reads the corresponding (the name foo must match here) job description
and carries out the configured actions.

Helmut

[Simon McVittie]

Post by Helmut Grohne
This functionality is entirely orthogonal to the one I was proposing.
You are talking about redirecting the init script invocation to a
running systemd instance. I am talking about sysvinit (as pid 1) to
execute systemd .service descriptions.

I'm sure we've been over this, on this very list, in several previous
threads. I used to think this was a great idea, too; I've been convinced
that it isn't feasible.

Part of the reason that systemd service descriptions are so simple is
that there's a significant amount of code in systemd to make them
simpler. Any wrapper that executed these descriptions would need to
provide the same semantics (or a large subset, and significant effort to
debug service descriptions that were only tested with "real systemd" and
make them work with "fake systemd").

One example is that because systemd uses cgroups to "capture" all the
processes from a service, the service doesn't need to be careful to
track all its child, grandchild, etc. processes and make sure they get
cleaned up. (Real-world example: gdm3 doesn't currently kill all its
child processes on exit,
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730653>. I suspect
that that bug just doesn't happen under systemd - which was probably the
only configuration tested upstream - because systemd + cgroups do that
work, once, for all services.)

Another example is that socket activation and automounting filesystems
means that many dependencies can be implicit. (Real-world example:
systemd services never need to depend on dbus.service or syslog.service,
only on the corresponding sockets, which are part of the default
dependency set.)

I'm sure there are more bits and pieces like those, that systemd
services are free to rely on for (potentially major) simplifications.

If you think you can prove me wrong, you're more than welcome to write
the tool that does this. I would predict that it will need to be written
in C/C++ to get enough control; it will either be Linux-specific or have
explicitly separate code paths for Linux and kFreeBSD; by the time it
works reliably, it'll look rather similar to systemd; and by the time
you've sorted out circular dependencies, it'll have about the same level
of coupling between components as systemd. If I'm wrong about that,
great; again, please prove me wrong.

I'm not going to write that tool, because I already have one; it's
called systemd. :-)

S

[Thomas Goirand]

Post by Simon McVittie
it'll look rather similar to systemd; and by the time
you've sorted out circular dependencies, it'll have about the same level
of coupling between components as systemd.

Why that? Dependency loops just have to be broken at run time when
calculating the boot order, I don't see why this would introduce high
coupling between components. Could you explain?

Thomas

[Helmut Grohne]

Post by Simon McVittie
I'm sure we've been over this, on this very list, in several previous
threads. I used to think this was a great idea, too; I've been convinced
that it isn't feasible.

Yes, I concur with the reasoning that I didn't quote here. In fact I
brought up many of those reasons on my own. I consider the eliding of
dependency information the most difficult hurdle to overcome.

Post by Simon McVittie
If you think you can prove me wrong, you're more than welcome to write
the tool that does this. I would predict that it will need to be written
in C/C++ to get enough control; it will either be Linux-specific or have
explicitly separate code paths for Linux and kFreeBSD; by the time it
works reliably, it'll look rather similar to systemd; and by the time
you've sorted out circular dependencies, it'll have about the same level
of coupling between components as systemd. If I'm wrong about that,
great; again, please prove me wrong.

I think this is 90% correct. Writing a 100% compatible .service
interpreter basically amounts to the same complexity as writing systemd.
But there is a twist here. The stupid portability argument that many
(including me) keep making over and over again. So rather than rewrite
100% of systemd to achieve 100% compatibility a feasible goal may(!) be
to rewrite 10% of systemd in a portable way to be able to run 50% of the
real world .service files. That's already a significant fraction in
terms of not having to maintain init scripts.

Unfortunately I will not be able to pull this alone. My earlier request
for help or even interest was met with silence. I guess that most people
are fine with running the reference implementation on a supported
kernel. Me too.

Now we drifted a fair bit from the original argument. Unlike systemd,
upstart has a head start here. It provides a somewhat limited reverse(!)
compatibility wrapper today. The design decisions made by the upstart
developers make it easier to write and port this wrapper than it is for
systemd for precisely the reasons not quoted from your mail.

Helmut

[Vitaliy Filippov]

Post by Simon McVittie
I'm sure there are more bits and pieces like those, that systemd
services are free to rely on for (potentially major) simplifications.

...and IMHO it's the main systemd problem: it's too complex. :)
And my personal opinion is that having implicit dependencies also isn't
good...

[Helmut Grohne]

actions on services). Do I misunderstand how upstart-job work? If I
install a package with an upstart job and a symlink to
/lib/init/upstart-job from /etc/init.d/ on Hurd, will it work?

Thanks for evaluating the methodology on Hurd! I am sure that this is
not caused by a fundamental flaw and would consider your observation to
be a bug in the implementation.

My idea was to make sure systems based on linux, kfreebsd and hurd
could keep using the init.d scripts even if upstart, systemd or openrc
is used by default on Linux, by reducing the maintenance burden for
package maintainers to keep such scripts working. Both upstart,
systemd, openrc, file-rc and sysv-rc are able to start daemons in
packages providing init.d scripts, and the LSB require such scripts to
keep working, so we would most likely have that support around until
we decide to drop LSB support in Debian.

The goal to have a portable interface is venerable and I for one fully
support it. While it is true that currently the LSB init script
interface is the supported method, I do not think that keeping this
support should be a long term goal. We had extensive discussion on this
already and if you read the TC discussion, you'll notice that getting
rid of this interface is among the top reasons for choosing an
alternative. This is why I argue to wrap up one of the contenders and
make it support the old interface reasonably well for some time, before
ditching it entirely.

Well, I do not add a standard. I keep the existing LSB standardized
init.d script standard and make them easier to maintain by reducing
the amount of information/code each package maintainer need to provide.

Essentially you are. Similarly you could argue that cdbs was not a
standard for Debian packages. Your helper creates a layer that needs to
be understood to interface with it. This is kind of a gray area, so I
would rather not oppose your solution if it turns out to work well. Good
luck with that!

Why not write an upstart job instead? It works with sysvinit today!

Because it only work with upstart at the moment. :)

Point taken. I still think that this is a limitation of the current
packaging rather than a fundamental one. If one assumes that the TC
decides in favour of upstart, this would be one of the first things to
fix in order to be able to drop init scripts in favour of job
descriptions. I am making no claims about the actual result though.

Helmut

[Thomas Goirand]

Post by Petter Reinholdtsen

Since last summer, OpenRC has full support for LSB headers. Also, I
believe that OpenRC is the only init system replacement which allows
to mix dependencies with LSB or it's own implementation.

That is not the case. Both systemd and upstart allow this as well.

I knew that both systemd and upstart can use LSB header scripts. But I
read that upstart (at least) would launch these only at the end of the
boot process, not mixing them in the boot order with upstart jobs. Can
any Upstart specialist (Steve maybe?) can tell if this is right or
wrong? What is systemd doing exactly with the LSB dependencies?

With OpenRC, what happens is that the LSB headers are transformed into
the internal syntax of OpenRC (eg: use, need, after, provide, etc.),
which makes it possible to have LSB header scripts be integrated within
the ordering calculation, just as if they were native OpenRC runscripts.
They are also involved in the dependency loop breaking system that has
recently been added to OpenRC.

BTW, Debian has a way too many LSB header scripts with Required-Start:
$all, which is very bad. A decent init system has to deal with this, and
there's no sane way to do so but arbitrarily breaking what the author of
the script wrote. A lintian warning telling that $all is just bad would
be a very nice thing. How does systemd & upstart deal with this pile of
garbage that Required-Start: $all is?

Cheers,

Thomas

[Tollef Fog Heen]

]] Thomas Goirand

Post by Thomas Goirand
$all, which is very bad. A decent init system has to deal with this, and
there's no sane way to do so but arbitrarily breaking what the author of
the script wrote. A lintian warning telling that $all is just bad would
be a very nice thing. How does systemd & upstart deal with this pile of
garbage that Required-Start: $all is?

$all obviously (as you point out) doesn't work well. Semantically, it
doesn't make sense to have more than one script depending on $all.
IIRC, systemd just ignores it.

[Sergey B Kirpichev]

Post by Tollef Fog Heen
$all obviously (as you point out) doesn't work well. Semantically, it
doesn't make sense to have more than one script depending on $all.

What I should use instead? Use case:
http://packages.qa.debian.org/m/monit.html
Usually, you want to start this service last and stop first.

[Tollef Fog Heen]

]] Sergey B Kirpichev

Post by Sergey B Kirpichev

Post by Tollef Fog Heen
$all obviously (as you point out) doesn't work well. Semantically, it
doesn't make sense to have more than one script depending on $all.

http://packages.qa.debian.org/m/monit.html

That's not a use case.

Post by Sergey B Kirpichev
Usually, you want to start this service last and stop first.

Why should it start last? (Stopping first I can see the point of, to
avoid spuriously restarting a daemon that's just been shut down, but it
should probably then just integrate with the init system so it knows if
the system is about to shut down and then avoid restarting daemons.)

[Sergey B Kirpichev]

Post by Tollef Fog Heen

Post by Sergey B Kirpichev
Usually, you want to start this service last and stop first.

Why should it start last?

Because monit is not systemd. monit - is only an utility for
proactive monitoring, not yet another init-replacement.

So, lets start services first, then start monitoring. Do
we want to play races with sysvinit? No. Now can you see the point?

Post by Tollef Fog Heen
but it should probably then just integrate with the init
system so it knows if the system is about to shut down and
then avoid restarting daemons.

The above use case is just a simplest example of such
integration. It's sysvinit responsibility to start/stop monit
as appropriate.

[Tollef Fog Heen]

]] Sergey B Kirpichev

Post by Sergey B Kirpichev

Post by Tollef Fog Heen

Post by Sergey B Kirpichev
Usually, you want to start this service last and stop first.

Why should it start last?

Because monit is not systemd. monit - is only an utility for
proactive monitoring, not yet another init-replacement.
So, lets start services first, then start monitoring. Do
we want to play races with sysvinit? No. Now can you see the point?

An init system that doesn't handle the case of something going «please
start $service» when it's already in the process of starting that
service, is buggy.

Post by Sergey B Kirpichev

Post by Tollef Fog Heen
but it should probably then just integrate with the init
system so it knows if the system is about to shut down and
then avoid restarting daemons.

The above use case is just a simplest example of such
integration. It's sysvinit responsibility to start/stop monit
as appropriate.

Sure, worst case is that monit, in the middle of shutting down, requests
a service start which won't ever happen (because the machine will be
shut down by then).

[Sergey B Kirpichev]

Post by Tollef Fog Heen
An init system that doesn't handle the case of something going «please
start $service» when it's already in the process of starting that
service, is buggy.

It's not the problem, as all (most) debian's init-scripts use
start-stop-daemon. The real problem - email notifications. You don't
want them while normal system startup, but if you start monit in the
middle of system initialization - you will got them.

Are you trying to sell me yet another init or do you suggest some
alternative solution *with* Debian's sysvinit, not using
"Should-Start/Stop: $all"? If the first, please stop. If
the second - please go ahead.

[Tollef Fog Heen]

]] Sergey B Kirpichev

Post by Sergey B Kirpichev
Are you trying to sell me yet another init or do you suggest some
alternative solution *with* Debian's sysvinit, not using
"Should-Start/Stop: $all"? If the first, please stop. If
the second - please go ahead.

No.

I'm pointing out why $all doesn't do what you want. «$all» means «after
everything else has started» and if you have two of those, you have a
loop. Loops are bugs.

In your particular case (and sysvinit), I'd say the admin should just
add dependencies on the monit script for the monitored services since I
don't think sysvinit support dynamically generating those dependencies
on boot. (If it does, I'm sure somebody will chime in with how to do it
for sysvinit.)

With systemd, I'd say a generator that adds After+Wants:
$monitored_services would be the right (and better) solution (this would
also solve the shutdown problem). I assume upstart has a reasonable way
to solve this, but I'm not familiar with what it should be.

[Clint Byrum]

Post by Tollef Fog Heen
]] Sergey B Kirpichev

Post by Sergey B Kirpichev
Are you trying to sell me yet another init or do you suggest some
alternative solution *with* Debian's sysvinit, not using
"Should-Start/Stop: $all"? If the first, please stop. If
the second - please go ahead.

No.
I'm pointing out why $all doesn't do what you want. «$all» means «after
everything else has started» and if you have two of those, you have a
loop. Loops are bugs.
In your particular case (and sysvinit), I'd say the admin should just
add dependencies on the monit script for the monitored services since I
don't think sysvinit support dynamically generating those dependencies
on boot. (If it does, I'm sure somebody will chime in with how to do it
for sysvinit.)
$monitored_services would be the right (and better) solution (this would
also solve the shutdown problem). I assume upstart has a reasonable way
to solve this, but I'm not familiar with what it should be.

Correct me if I'm wrong, but there are basically two problems.

1) Some services are fragile and will behave badly if started before
some explicit services (nfsd needs nis-things running if nis is in use)
2) Some services are meant to be started after the system has reached a
steady state (monit, cron, etc).

For (1), upstart uses an upstart job I wrote, called wait-for-state.
This should be built into upstart, but ENOROUNDTUITS. You basically put
this in your pre-start:

pre-start exec start wait-for-state WAITER=$JOB WAIT_FOR=thingtowaitfor

This job will wait for the job if it is starting, or start it if it is
stopped, but can work in reverse for stopping/stopped things as well. This
works fairly reliably, but it is somewhat confusing. Ideally upstart
would just have a 'while' condition instead of or in addition to 'start
on'. It is, btw, a myth that Upstart is not state based. It is, it just
makes it a huge PITA to actually use the state it tracks quite nicely.

For (2), the system startup itself needs some re-working from the way
Ubuntu has done it and upstart works in Debian. Right now, you basically
have carefully orchestrated plumbing events that lead up to the system
reaching the default runlevel. At that point, we go into hyper-parallel
mode because most daemons should be:

start on runlevel [2345]
stop on runlevel [016]

This works fine for things like apache and mysql, because they can start
in parallel and if your web app doesn't work for a few seconds while
mysql gets its stuff together oh-well. Trying really hard to get all of
the relationships right for all of the daemons in Debian is not going to
work well. There is no reason that anything that normally communicates
over the network should ever assume its dependent services are already up.

For the things that matter a lot, the wait-for-state method exists.

But for monit, we want to start after basically everything, so we go
after sysvinit is completely done:

start on stopped rc RUNLEVEL=[2345]
stop on starting rc RUNLEVEL=[016]

This will at least start those things after mysql and apache are starting,
but rc is not blocked on them being _started_. To do that, one just
needs to create some grouping jobs like this:

--/etc/init/network-services.conf--
start on runlevel [2345]
stop on runlevel [016]
description "All Network Services"
--end--

Then all the jobs that used runlevel just migrate to this:

start on starting network-services
stop on stopped network-services

Aside from making more sense to humans, that would allow things like
monit to say:

start on started network-services
stop on stopping network-services

This is just one of those things that requires time, and only fixes
really subtle bugs.

[Sergey B Kirpichev]

Post by Tollef Fog Heen
I'm pointing out why $all doesn't do what you want.

It's exactly what I want.

Post by Tollef Fog Heen
«$all» means «after everything else has started» and if you
have two of those

You have a bug. Yes, some packages abuse $all, I admit this,
but not all of them (e.g. monit).

Post by Tollef Fog Heen
In your particular case (and sysvinit), I'd say the admin should just
add dependencies on the monit script for the monitored services since I
don't think sysvinit support dynamically generating those dependencies
on boot. (If it does, I'm sure somebody will chime in with how to do it
for sysvinit.)

AFAIK, this can be done with /etc/insserv/overrides/
That is not a problem *for human* to add a file
in /etc/insserv/overrides/ and override monit's LSB-headers.
The problem is not the mechanisms, like after+wants, not the
output format for this generator (systemd stuff or
LSB-headers) - but the generator itself.

So, I don't buy this "solution", sorry.

[Thomas Goirand]

Post by Tollef Fog Heen
]] Sergey B Kirpichev

Post by Sergey B Kirpichev
Are you trying to sell me yet another init or do you suggest some
alternative solution *with* Debian's sysvinit, not using
"Should-Start/Stop: $all"? If the first, please stop. If
the second - please go ahead.

No.
I'm pointing out why $all doesn't do what you want. «$all» means «after
everything else has started» and if you have two of those, you have a
loop. Loops are bugs.
In your particular case (and sysvinit), I'd say the admin should just
add dependencies on the monit script for the monitored services since I
don't think sysvinit support dynamically generating those dependencies
on boot. (If it does, I'm sure somebody will chime in with how to do it
for sysvinit.)
$monitored_services would be the right (and better) solution (this would
also solve the shutdown problem). I assume upstart has a reasonable way
to solve this, but I'm not familiar with what it should be.

The only viable solution is to integrate monit support inside the init
system, like what's currently happening in OpenRC:

http://qnikst.github.io/posts/2013-11-06-openrc-supervision.html

with patch available here:

https://github.com/qnikst/openrc/compare/s-vision

Note that it is on my todo list to evaluate this patch, but I didn't
have the time to do that work yet. Any contribution would be welcome
from anyone willing to test it, and see if it integrates well with the
current OpenRC package.

Note that this has verry little to do with *process* supervision, like
it would be done with s6 (http://skarnet.org/software/s6/) which is also
on the OpenRC upstream todo list.

Cheers,

Thomas Goirand (zigo)

[Petter Reinholdtsen]

[Tollef Fog Heen]

Post by Tollef Fog Heen
I'm pointing out why $all doesn't do what you want. «$all» means «after
everything else has started» and if you have two of those, you have a
loop. Loops are bugs.

That is a common misunderstanding of what $all means, and probably the
reason why insserv, systemd and openrc handle it differently.

$all was introduced by SuSe in the insserv package, which Debian also
uses to order init.d scripts, and for me that mean insserv is the one
defining what $all mean. The $all facility is not defined in the LSB
3.1.0. In insserv, $all means after all scripts not depending on $all.
This is how it has been used in the two only distributions where the
facility has been in use (Debian and SuSe - are there others?). I thus
suspect most or all init.d scripts in Debian today are based on how
insserv uses $all to order init.d scripts, given that this has been the
reference implementation when dependencies were introduced in init.d
scripts.

A better definition of $all, which to me make more sense than the
current definition in insserv, and which I suspect also would be less
confusing, could be "all scripts not depending directly or indirectly on
$all". This would allow scripts depending on $all to also depend on
each other, and ensure correct ordering also in this case.

According to Tollef, systemd simply ignore $all, inserting scripts with
that dependency as if $all were not present.

And according to Thomas, OpenRC assume scripts depending on $all also
depend on other scripts depending on $all, conclude there is a loop and
try to break the loop at some random point in the perceived loop.

If I understand correctly, Upstart leave it to insserv to order init.d
scripts.

Here are some examples how this will lead to incorrect ordering. Given
scripts A, B and C, where B depend on $all and C depend on $all, both
the correct order would be (A, B, C) and (A, C, B) - both are correct, B
and C can be started in parallel. systemd can end up with the ordering
(B, A, C), (C, B, A), (B, C, A) and (C, A, B) in addition to the correct
ones, because it ignore $all and there are no other dependencies to take
into account. OpenRC see a dependency loop B - C - B and will break it
at a random point, ending by chance up with on of the correct orderings.

Luckily there are not too many scripts with $all listed as its
dependency. But those that use it, really need to run after most of the
scripts in the boot sequence, without being able to list them all.
rc.local is one example, which by definition should be among the last
scripts to run.

[Thomas Goirand]

Post by Petter Reinholdtsen
And according to Thomas, OpenRC assume scripts depending on $all also
depend on other scripts depending on $all, conclude there is a loop and
try to break the loop at some random point in the perceived loop.

That is correct, however, the way it is done currently, it does
approximately what one would expect in Debian! :)

Anyway, that's not a clean implementation. So, thanks a lot for this
definition matching sysv-rc. So this may lead to newer code.

The author of lsb2rcconf (eg: Dmitry Yu Okunev) will work on it. What
will be done is scanning all LSB header scripts for $all, and fix the
conversion to the OpenRC internal format (at least that's what he wrote
on IRC).

Cheers,

Thomas Goirand (zigo)

[Thomas Goirand]

Post by Sergey B Kirpichev

Post by Tollef Fog Heen
$all obviously (as you point out) doesn't work well. Semantically, it
doesn't make sense to have more than one script depending on $all.

http://packages.qa.debian.org/m/monit.html
Usually, you want to start this service last and stop first.

Let's say you want to run monit in Hurd, then it must *not* start last.
The last one must always be the hurd console.

Thomas

[h***@gentoo.org]

Post by Sergey B Kirpichev
http://packages.qa.debian.org/m/monit.html
Usually, you want to start this service last and stop first.

The question is, before or after rc.local?

[Sergey B Kirpichev]

Post by h***@gentoo.org

Post by Sergey B Kirpichev
http://packages.qa.debian.org/m/monit.html
Usually, you want to start this service last and stop first.

The question is, before or after rc.local?

Doesn't matter) rc.local shouldn't be used by local
admin to start services from. Why not use usual init-script?

Post by h***@gentoo.org

Post by Sergey B Kirpichev
So, lets start services first, then start monitoring. Do we want to
play races with sysvinit? No. Now can you see the point?

We don't have to race it: by telling service managers other than monit
(sysvinit, openrc, sysv-rc, etc. etc.) to leave what monit concerns
alone can do the trick.

Yes, that's easy. For human.

[Kevin Chadwick]

Post by Sergey B Kirpichev
Doesn't matter) rc.local shouldn't be used by local
admin to start services from. Why not use usual init-script?

I wouldn't be surprised if rc.local has been around longer than Debian
and is meant to run at the end. Particularly for a service that isn't
packaged it may be useful and expected to run last. It seems perfectly
logical for a user to expect a "local" service or command to run last ie
as if a user did so after boot up. The special hurd case should run
after rc.local as a special case perhaps an include ./rc.local.oddball.

The arguments online of services should be shutdown gracefully in case
they have problems on the next bootup by upstart and systemd seems to
be nonsense.

On OpenBSD you have rc.shutdown but in any case if the system dies or
crashes, plug pulled etc., then services should start just fine on
reboot or be re-written rather than being flaky rubbish

In fact in that case "abusing" rc.local means a higher likelihood of
testing for and removing flaky services or fixing bugs before that
annoying time of things breaking which almost always happens at the
worst time possible.
--
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
_______________________________________________________________________

[Sergey B Kirpichev]

Post by Kevin Chadwick

Post by Sergey B Kirpichev
Doesn't matter) rc.local shouldn't be used by local
admin to start services from. Why not use usual init-script?

I wouldn't be surprised if rc.local has been around longer than Debian
and is meant to run at the end. Particularly for a service that isn't
packaged it may be useful and expected to run last.

Why you can't just write a regular init-script
to start (and stop!) this service? rc.local is not flexible to this.

[Wouter Verhelst]

Post by Sergey B Kirpichev

Post by Kevin Chadwick

Post by Sergey B Kirpichev
Doesn't matter) rc.local shouldn't be used by local
admin to start services from. Why not use usual init-script?

I wouldn't be surprised if rc.local has been around longer than Debian
and is meant to run at the end. Particularly for a service that isn't
packaged it may be useful and expected to run last.

Why you can't just write a regular init-script
to start (and stop!) this service? rc.local is not flexible to this.

Doesn't matter. rc.local is an interface that has been around since
forever, and which is *meant* for local admins to use.

Whether it is flexible or not may be true, but is irrelevant for this
discussion. No, we should not depend on it for Debian; but we should
provide the interface for system administrators who wish to use it,
because it is not Debian's place to tell them that they cannot use that
interface.

of course, if it would be difficult to provide rc.local functionality in
a given init system, then that would be a different matter entirely, in
which case it might make sense to stop providing rc.local functionality;
but I doubt that is the case, since rc.local is just a script, and
calling it when everything else has been started should be ridiculously
easy in any init system.

[Matthias Urlichs]

Hi,

Post by Wouter Verhelst
discussion. No, we should not depend on it for Debian; but we should
provide the interface for system administrators who wish to use it,
because it is not Debian's place to tell them that they cannot use that
interface.

It's not our place to tell people that they _cannot_ use it, but it's a
good place to add a "consider writing a .service file if you start daemons
here; read the XXX manpages to learn more".

[Tobias Frost]

Post by Matthias Urlichs
Hi,

Post by Wouter Verhelst
discussion. No, we should not depend on it for Debian; but we should
provide the interface for system administrators who wish to use it,
because it is not Debian's place to tell them that they cannot use that
interface.

It's not our place to tell people that they _cannot_ use it, but it's a
good place to add a "consider writing a .service file if you start daemons
here; read the XXX manpages to learn more".

Well, just my two cents: There are other (IMHO) legitmiate uses for rc.local
_except_ starting daemons. For example I (mis)use it to tweak flashcache
settings after booting is complete or on my Raspberry Pi (used DLNA media
renderer) to play a jingle to indicate "boot complete, you may now
interact"....

[Kevin Chadwick]

Post by Matthias Urlichs

Post by Wouter Verhelst
discussion. No, we should not depend on it for Debian; but we should
provide the interface for system administrators who wish to use it,
because it is not Debian's place to tell them that they cannot use that
interface.

It's not our place to tell people that they _cannot_ use it, but it's a
good place to add a "consider writing a .service file if you start daemons
here; read the XXX manpages to learn more".

I agree but more than that why should I waste my time, I have no
intention of ever writing a .service file or anything much longer than
one-liners else I'd say that something is wrong in one of a few places
and most likely the program design.

I get the plus of my scripts running on any system, even Windows or a c
loop embedded device.

Plus I stop services with the likes of pkill as when service stop fails
I would prefer to know how anyway and can use them on any system or with
any favourite of myself or others whether it's monit, nagios etc. etc.
or any shell.
--
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
_______________________________________________________________________

[Sergey B Kirpichev]

Post by Wouter Verhelst

Post by Sergey B Kirpichev

Post by Kevin Chadwick

Post by Sergey B Kirpichev
Doesn't matter) rc.local shouldn't be used by local
admin to start services from. Why not use usual init-script?

I wouldn't be surprised if rc.local has been around longer than Debian
and is meant to run at the end. Particularly for a service that isn't
packaged it may be useful and expected to run last.

Why you can't just write a regular init-script
to start (and stop!) this service? rc.local is not flexible to this.

Doesn't matter. rc.local is an interface that has been around since
forever, and which is *meant* for local admins to use.

But not to abuse this interface and use one in a wrong way.

Post by Wouter Verhelst
Whether it is flexible or not may be true, but is irrelevant for this
discussion. No, we should not depend on it for Debian; but we should
provide the interface for system administrators who wish to use it,
because it is not Debian's place to tell them that they cannot use that
interface.

The point is that I'm aware about such drawbacks of using
Should-Start/Should-Stop $all for monit, but I don't see a better
solution.

[Wouter Verhelst]

Post by Sergey B Kirpichev

Post by Wouter Verhelst

Post by Sergey B Kirpichev

Post by Kevin Chadwick

Post by Sergey B Kirpichev
Doesn't matter) rc.local shouldn't be used by local
admin to start services from. Why not use usual init-script?

I wouldn't be surprised if rc.local has been around longer than Debian
and is meant to run at the end. Particularly for a service that isn't
packaged it may be useful and expected to run last.

Why you can't just write a regular init-script
to start (and stop!) this service? rc.local is not flexible to this.

Doesn't matter. rc.local is an interface that has been around since
forever, and which is *meant* for local admins to use.

But not to abuse this interface and use one in a wrong way.

It's not abuse. It cannot be abuse!

It is an interface that is meant for the local administrator to use. It
is trivially easy to support, and many many _many_ local admins will use
it for whatever they want to. And that's fine, because that is _exactly_
what it's for.

It is not Debian's place to decide what is the "right" or the "wrong"
way for local administrators to use. Debian ships an empty rc.local
file, and expects a local administrator to have fun using it.

I will agree with you that bypassing the init script system and just
dumping hundreds of lines in rc.local is a bad idea. But if a local
administrator decides that this is what they want to use, then by all
means they should use it.

[Adam Borowski]

Post by Wouter Verhelst

Post by Sergey B Kirpichev

Post by Wouter Verhelst
Doesn't matter. rc.local is an interface that has been around since
forever, and which is *meant* for local admins to use.

But not to abuse this interface and use one in a wrong way.

It's not abuse. It cannot be abuse!
It is an interface that is meant for the local administrator to use. It
is trivially easy to support, and many many _many_ local admins will use
it for whatever they want to. And that's fine, because that is _exactly_
what it's for.
It is not Debian's place to decide what is the "right" or the "wrong"
way for local administrators to use. Debian ships an empty rc.local
file, and expects a local administrator to have fun using it.
I will agree with you that bypassing the init script system and just
dumping hundreds of lines in rc.local is a bad idea. But if a local
administrator decides that this is what they want to use, then by all
means they should use it.

And please do not break it, or you'll have hordes of sysadmins with torches
and pitchforks after you.

I for one tend to write a whole /etc/init.d/ script for a minor at-boot
task[1], but I'd join the lynch mob because I see it being used everywhere
and _I_ would have to fix some resulting breakage.

So whatever init system you ship, please execute rc.local, mm'kay?



[1]. With IIRC two exceptions. One just to run "df >/dev/null", the reason
that's not a no-op involving a noisy disk and slow spin-up.

[Holger Levsen]

package: lintian
severity: wishlist

Hi,

Post by Thomas Goirand
$all, which is very bad. A decent init system has to deal with this, and
there's no sane way to do so but arbitrarily breaking what the author of
the script wrote. A lintian warning telling that $all is just bad would
be a very nice thing.

cheers,
Holger

[Holger Levsen]

package: lintian
severity: wishlist
x-debbugs-cc: debian-***@lists.debian.org,pkg-sysvinit-***@lists.alioth.debian.org

Hi,

Post by Thomas Goirand
$all, which is very bad. A decent init system has to deal with this, and
there's no sane way to do so but arbitrarily breaking what the author of
the script wrote. A lintian warning telling that $all is just bad would
be a very nice thing.

cheers,
Holger

[Bastien ROUCARIES]

Post by Thomas Goirand

Post by Petter Reinholdtsen

Since last summer, OpenRC has full support for LSB headers. Also, I
believe that OpenRC is the only init system replacement which allows
to mix dependencies with LSB or it's own implementation.

That is not the case. Both systemd and upstart allow this as well.

I knew that both systemd and upstart can use LSB header scripts. But I
read that upstart (at least) would launch these only at the end of the
boot process, not mixing them in the boot order with upstart jobs. Can
any Upstart specialist (Steve maybe?) can tell if this is right or
wrong? What is systemd doing exactly with the LSB dependencies?
With OpenRC, what happens is that the LSB headers are transformed into
the internal syntax of OpenRC (eg: use, need, after, provide, etc.),
which makes it possible to have LSB header scripts be integrated within
the ordering calculation, just as if they were native OpenRC runscripts.
They are also involved in the dependency loop breaking system that has
recently been added to OpenRC.
$all, which is very bad. A decent init system has to deal with this, and
there's no sane way to do so but arbitrarily breaking what the author of
the script wrote. A lintian warning telling that $all is just bad would
be a very nice thing.

Please report it against Lintian. I will fix it.

Bastien

Post by Thomas Goirand

Post by Petter Reinholdtsen
How does systemd & upstart deal with this pile of

garbage that Required-Start: $all is?
Cheers,
Thomas
--
with a subject of "unsubscribe". Trouble? Contact

[Joey Hess]

#!/lib/init/init-d-script
### BEGIN INIT INFO
# Provides: daemon
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: nice daemon
# Description: Provide service to others
### END INIT INFO
DAEMON=/usr/sbin/daemond
As for the line counting in the subject, I decided to ignore commented
lines. Including those, we end up on 11 lines. :)

If there was ever any doubt that LSB's abuse of comments in init script
headers was a bad idea (of the sort committees commonly develop),
I think you've conclusively proven it here.

[Marko Randjelovic]

On Wed, 5 Feb 2014 22:31:09 +0100

A few months ago I drafted an idea to rewrite init.d scripts to use a
common implementation and only specify the unique parts in the init.d
scripts themselves. That draft can be found on
<URL: http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html >.

...

Short and to the point, and in the simple case only list the path to
the daemon to start. The code to implement init.d scripts is moved to
/lib/init/init-d-script, and the redundant code spread across
/etc/init.d/ can be dropped.
A few days ago I picked up the idea again, and wrote a more complete
draft of the /lib/init/init-d-script. The code is available in the
simpler-init-scripts in the sysvinit GIT repository, available from
<URL: http://anonscm.debian.org/gitweb/?p=collab-maint/sysvinit;a=shortlog;h=refs/heads/simpler-init-scripts >.
I've tested it on a few packages, and believe the code is ready for
wider testing.

...

to gather feedback on the idea. Will it work for your package, or are
some more hooks needed? Second, I wonder where such script best would
belong. My initial idea is to put it in the initscripts package,
installed on almost all Debian systems, but I suspect sysvinit-utils
is a good place too. I plan to use the system in the initscripts
package, and am relucant to add new dependencies to it, as this would
make the new dependency a required package.
Comments?

Looks nice, I drafted a similar idea, please look here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#871