F15 Feature - convert as many service init files as possible to the native SystemD services
mzerqung at 0pointer.de
Fri Nov 26 02:05:51 UTC 2010
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.
> > To summarize this: the current logic of cron is not pretty. And it
> > duplicates process spawning and babysitting which already exists in way
> > too many daemons,
> I think you'll find the execution of processes is a comparatively small
> part of cron.
Well, and that's why it is also very limited.
> And anyway, "process spawning and babysitting" will
> _always_ exist in many different daemons, unless you want to run the
> whole system within a single systemd process.
Sure, no doubt about that. But unifying this for system stuff is a good
thing, not a bad thing.
> 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.
Lennart Poettering - Red Hat, Inc.
More information about the devel