Lennart Poettering pÃÅe v PÃ 26. 11. 2010 v 03:05 +0100: > On Fri, 26.11.10 02:07, Miloslav TrmaÄ (mitr@xxxxxxxx) wrote: > > Lennart Poettering pÃÅe v PÃ 26. 11. 2010 v 01:27 +0100: > > > On Thu, 25.11.10 17:33, Tomas Mraz (tmraz@xxxxxxxxxx) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
