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.
>
> <dream>
> 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. <wakeup/> But now we call it "exec" here and "ExecStart" there,
> "export" here and "Environment" there, and "chdir" here and
> "WorkingDirectory" there. Bummer.
> </dream>
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-devel-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
