F15 Feature - convert as many service init files as possible to the native SystemD services

[Miloslav Trmač]

Lennart Poettering píše v Pá 26. 11. 2010 v 03:05 +0100:
> On Fri, 26.11.10 02:07, Miloslav Trmač (mitr at volny.cz) wrote:
> > Lennart Poettering píše v Pá 26. 11. 2010 v 01:27 +0100:
> > > On Thu, 25.11.10 17:33, Tomas Mraz (tmraz at redhat.com) wrote:
> > > And also, cron does a couple of really nasty things. For example it
> > > wakes up in regular intervals to check if a job is ready to run. It does
> > > so to deal with wallclock time changes/suspends. In systemd we are
> > > working on a different way to solve this, so that we can actually sleep
> > > as long as possible, and don't have to wake up in regular
> > > intervals.
> > Great.  You can fix cron then, this does not mean it is necessary to
> > integrate the two.
> 
> Well, I actually believe we should design an OS here, not just a set of
> independent tools. And that means I think closer integration is good and
> only has benefits.
At the very least, closer integration makes troubleshooting
significantly more difficult.  Each point where separate tools interact
is a point where it is possible, and in UNIX often easy, to insert
debugging instrumentation.

If the system integrates everything into one process, the only remaining
troubleshooting mechanisms are integrated logging (which is by
definition unsatisfactory - if a problem was foreseen enough to be
logged, it was probably also foreseen enough to be avoided), debugger
(useless for non-programmers, useless for non-expert programmers that
need to fix things in a hurry, practically useless with -O2) and
systemtap (only a little better than a debugger, and not available for
most programs).

"Design an OS" means that the system _design_ should fit well together,
nothing more.

> > It would be much much better for the ecosystem to extract these parts
> > of systemd into a library (perhaps standalone, perhaps interacting
> > with the system-wide systemd runtime) that can be used in any other
> > process that needs to run a task in a separately tracked "daemon
> > group".  Mirek
> 
> Well, I don't think that that technically makes any sense. Sorry.
Care to elaborate?  Look at sshd: it needs to start per-user sessions
from a single daemon.  Wouldn't it make sense to track these as cgroups
recognized by systemd?  Crond is _exactly_ the same thing.  Any other
remote access protocol (POSIX batch facilities, func, X server accepting
remote clients, and anything else that isn't currently a part of the
system and thus can't be rewritten as part of systemd) would benefit
from this facility.

AFAICS it would be clearly useful to be able to delegate the control of
"daemon group" creation to other processes.  Why doesn't it make sense?
	Mirek