Laurent Bercot <ska-devel@???> writes:

A leading remark: This is based on an existing system I have implemented
(originally for Debian 5) working in the described way. The code is
proprietary as I'm one of those evil guys who want to (and do) write code
for a living despite the 'free software community' traditionally hates
me (not entirely their fault because almost all people handling skills I
have at all were acquired by 'trial and error on the internet' and they
used to be pretty grueseome [and to a degree, still are]).

> On 06/08/2015 16:00, Rainer Weikusat wrote:
>> That's all nice and dandy but it all boils down to 'the code executed by
>> the init script was deficient in some way'.
>
> Yes, just like root exploits boil down to "the code executed by the
> suid program was deficient in some way".
> My point is that you shouldn't need to have 40 lines of boilerplate
> to sanitize your init script before you run it; if it's so fragile,
> then it's badly designed.

UNIX(*) and therefore, Linux, provides two system calls named fork and
exec which can be used to create a new process while inheriting certain
parts of the existing environment and to execute a new program in an
existing process, keeping most of the environment. This implies that it
is possible to write a program which performs a particular 'environment
setup task' and then executes another program in the change
environment. 'nohup' is a well-known example. Because of this, instead
of "40 lines of boilerplate" in every init script, almost all of which
is identical, it's possible to identify common tasks and write programs
to handle them which can be chained with other programs handling other
tasks, Eg, as a real world example, a command to start a certain Java
application I happen to be dealing with looks like this:

daemon chdir $DIR monitor -n jboss -g $RUNAS chids -u $RUNAS $JBOSS_HOME/bin/run.sh -b 127.0.0.1

'daemon' creates a daemon process and execvps its arguments in it.

'chdir' changes to a directory passed as first argument and execvps the
remaining arguments.

'monitor' forks, performs a few other things (creates a control socket
with a well-known name) and execvps its arguments in the new process. As
the name might suggests, it works as process monitor/ supervisor.

'chids' changes uid and gid as specified on the command and and execvps
its remaining arguments.

And that's finally the jboss start script. I have some more tools of
this kind because whenever I need a new, generic process management task
to be performed, I write a new program doing that which can be used in
concert with the existing ones.

[...]

>> [systemd]
>> Is it? Or is it an extremely incomplete, ad hoc designed programming
>> language with a service manager and a truckload of other potentially
>> useful stuff attached to it in order to encourage people to swallow the
>> language?

[...]

> Know your enemy. It's easy and tempting to rant for days on systemd's
> weaknesses; but it's also vital to acknowledge its strengths.

<sarcasm>
Considering that SuSE almost adopted updstart, it came just at the right
to keep the traditional order of the universe where "Fedora guys"
'contribute' and moan about Canonical 'not giving back' intact.
</scarcasm>