On 06/08/2015 20:18, Rainer Weikusat wrote:
> 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

Yes. You are describing chain loading. (And the system call is named
execve, if you want to be pedantic.)


> 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.

What you are saying is that your approach is exactly the same as the
one found here:
http://skarnet.org/software/execline/
and here:
http://skarnet.org/software/s6/

It's free software, it works, it's maintained, and the author happens to
read the dng list, hoping to find technical interlocutors that share his
concerns for the future of GNU/whatever/Linux.

Are you one of them ? Good. Let's talk.

Now, chain loading is great, and all the necessary tools that perform
process state changes already exist, but that's not enough to make
init scripts safe. When you want to sanitize a process, or when you're
doing any kind of security really, you cannot have an "allow everything
by default and deny specific things" approach: fork your process from
the user's shell, then sanitize the environment, the fds, the cwd, etc.
You *will* forget something at some point; if you don't, the person who
writes the next init script will. Instead, you have to use a "deny
everything by default" approach: in the case of init scripts, that means
always starting daemons with the same, sanitized, environment. That can
only be done with a supervision system, as explained at
http://skarnet.org/software/s6/overview.html

And a supervision system itself is a great thing, but it's not enough,
because it does not handle dependencies between longrun services (i.e.
daemons that can be supervised) and oneshot services (i.e. stuff you run
once to change the machine state, but that do not leave a long-lived
process around). That is where a real service manager is needed.

As loath as I am to admit it, systemd *is* both a supervision system
and a service manager. It does machine initialization, daemon supervision,
and state changes - badly, but it does them. And no amount of mucking with
init scripts, no matter how much chain loading you use, is going to
accomplish the same.

The solution is not in criticizing, it's in doing. I have the supervision
system, and I'm working on the service manager. But this will be all for
naught if systemd opponents can't be convinced that it is necessary: the
admin who wants a service manager will hear "sure, systemd does that!" on
one side, and "nah, this is purely systemd propaganda, you don't really
need that shit" on the other side. Guess what they will choose.

The other side should be able to answer "sure, you can use *this* piece of
software, or *this* other one, to do what you want, and you don't have
to put up with all the systemd crap for this". It's the only way we can
make it work.

--
Laurent