Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Fri, Nov 1, 2013 at 2:51 PM, Russ Allbery <rra@debian.org> wrote:
> Peter Dolding <oiaohm@gmail.com> writes:
>
>> The one property about systemd unit files that is extremely good is
>> there are no multi line commands. Every command is a single line.
>
> Yes, that's exactly what I think is obnoxious. I prefer the upstart
> syntax, which avoids the temptation to write unreadable one-line shell
> constructs. (Indeed, several have already been posted in recipes in
> various threads on debian-devel about this.) You can, of course, be
> disciplined about this when writing systemd helper scripts by always
> exernalizing the shell script into a separate file, but I really like that
> upstart lets me inline trivial shell fragments without worrying about
> that while still keeping them readable.
http://www.freedesktop.org/software/systemd/man/systemd.service.html
Systemd in fact support the exec lines being written many times.
ExecStart= is recommend against being used many due to using XDG
desktop processing by somethings. But that is something can could be
changed in time. Personally I think it should be changed.
http://www.freedesktop.org/software/systemd/man/systemd.service.html
ExecStartPre=, ExecStartPost= can be written many times.
ExecStartPre= rm somewhere
ExecStartPre= touch somewhere
That is in fact valid and both will run in order. From the start of
unit file to end.
In fact lot of cases I see one line entries in systemd and I see bad
form. Unless one line has like if or for statements its really bad
form inside systemd.
Yes systemd supports ; split statements most cases this should not be
used in most cases. Its cleaner in the log to see what statement
failed the multi line way.
Really I would like to see some of those unreadable single line
script. I am a little bit suspect they will be people not
understanding systemd. So failing to split over many Exec statements
for clear readability.
Even using upstart you don't stop people from doing unreadable shell script.
>
> I personally don't find any of your other arguments persuasive (maybe I'm
> too used to writing portable /bin/sh scripts), but I do see where you're
> coming from.
I have been the the receiving end of too many not portable shell
scripts. My big problem about not being able to set it is what if
Ubuntu and Debian decide on a different /bin/sh to each other. No
way to set no way to work around this with current upstart.
Its not like /bin/sh has not changed in the past.
https://wiki.ubuntu.com/DashAsBinSh Has everyone forgot the screw ups
that happened when bash was swapped for dash with the old sysvinit.
They were workable around under sysvinit by setting the scripts that
required bash to bash. So means to change the shell is remembering
historic stuff ups.
There is already complaints with upstart with canonical controlling
the upstream. So we have to be very careful with dependencies.
Basically upstart is lacking one key feature. If it not fixed it
will come back and bite us. Really I would like to see this fixed
before debian takes up upstart if debian takes up upstart at all.
Openrc and systemd both can work around the prior issues that have
effected sysvinit in history.
Replacement we have to be able to beat up like sysvinit and still have it work.
SourcePath= option exists in systemd to mark a location of a file that
the current file is generated from. I don't know openrc or upstart
to say if either of them have this functionality as well.
History tells us what is likely to happen again. History is what
against taking in upstart in it current form. Upstart in it current
form cannot get past the same issues sysvinit got around without major
trouble. It should only be a minor fix to add a means to define
/bin/sh as a different executable per service.
Peter Dolding
Reply to: