[Helmut Grohne]
> This idea has been brought up a fair number of times now. While others
> have already pointed out, that this is basically the approach taken by
> OpenRC, we have a very similar implementation in the archive for far
> longer. It's called upstart!
>
> The relevant bits can be found in insserv, watch out for
> "/lib/init/upstart-job". It takes things one step further though.
> Instead of having an interpreted script, it right out replaces the
> init script with a symbolic link to the mentioned helper. That in
> turn can derive the job name from argv[0] and use the existing
> upstart job description.
Ah, had completely forgotten about that script./lib/init/upstart-job.
Thank you for bringing it to my attention. Found the
/lib/init/upstart-job script in the upstart package and the code to
allow insserv to run '/etc/init.d/script lsb-header' to generate the
LSB header from the upstart job.
It make sure /etc/init.d/ scripts are available for machines using
upstart, but do not make sure the script work on machines without
upstart. I guess that could be solved by moving the
/lib/init/upstart-job file out of the upstart package and into a more
suitable package, but a more extensive rewrite is also needed (it
expect start, stop, status and reload to be commands able to take
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?
Testing... Nope, did not work:
root@hurdtest:~# cat /etc/init/ssh.conf
# ssh - OpenBSD Secure Shell server
#
# The OpenSSH server provides secure shell access to the system.
description "OpenSSH server"
start on runlevel [2345]
stop on runlevel [!2345]
respawn
respawn limit 10 5
umask 022
env SSH_SIGSTOP=1
expect stop
# 'sshd -D' leaks stderr and confuses things in conjunction with 'console log'
console none
pre-start script
test -x /usr/sbin/sshd || { stop; exit 0; }
test -e /etc/ssh/sshd_not_to_be_run && { stop; exit 0; }
test -c /dev/null || { stop; exit 0; }
mkdir -p -m0755 /var/run/sshd
end script
# if you used to set SSHD_OPTS in /etc/default/ssh, you can change the
# 'exec' line here instead
exec /usr/sbin/sshd -D
root@hurdtest:~# ls -l /etc/init.d/ssh
lrwxr-xr-x 1 root root 21 Feb 6 09:49 /etc/init.d/ssh ->
/lib/init/upstart-job
root@hurdtest:~# /etc/init.d/ssh status
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service ssh status
/etc/init.d/ssh: 58: /etc/init.d/ssh: initctl: not found
Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the status(8) utility, e.g. status ssh
/etc/init.d/ssh: 70: /etc/init.d/ssh: status: not found
root@hurdtest:~# /etc/init.d/ssh lsb-header
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service ssh lsb-header
/etc/init.d/ssh: 58: /etc/init.d/ssh: initctl: not found
The script you are attempting to invoke has been converted to an Upstart
job, but lsb-header is not supported for Upstart jobs.
root@hurdtest:~#
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.
> So yeah, the approach taken is one that is known to be good. The
> main downside I see with your particular implementation is that your
> answer to the problem of too many standards is adding yet another
> one.
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.
> Why not write an upstart job instead? It works with sysvinit today!
Because it only work with upstart at the moment. :)
--
Happy hacking
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206104724.gh1...@ulrik.uio.no
