On Nov 27, 2007 3:10 AM, Shawn Rutledge <[EMAIL PROTECTED]> wrote: > On Nov 26, 2007 4:31 PM, Scott James Remnant <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-11-26 at 13:40 -0700, Shawn Rutledge wrote: > > > > > On Nov 26, 2007 2:01 AM, Scott James Remnant <[EMAIL PROTECTED]> wrote: > > All init needs to do is spawn processes, and reap them when they die; > > with some handling for determining when it needs to do the former and > > working out what to do about the latter. > > Well at first glance I was inclined to think that when upstart aims to > replace crond and atd, those might be good examples of functionality > that could be plugins. Then again, the whole point is that events > trigger processes to be launched, and the state of the system clock > can be just another kind of event, so making upstart have cron > functionality is pretty much aligned with its usual behavior.
Given the case made elsewhere, for small simple code, I'm wondering what you really gain by bringing cron & atd into 1 process. Currently there's a choice of cron packages to which may suit some deployments better than others. Making a monolithic program in 1 package, will mean choosing the right behaviour, which then may become a limititation, should say the machine be part of some cluster, with distributed batch processing (or the unfeasible complication of implementing all possible behaviours in a critical system daemon). At least Ubuntu /sbin/init is dymamically linked, rather than traditional static linking, so assuming the libc is the same that is shared with later processes, then at least code isn't being duplicated in system RAM for no good reason. Whilst many design choices from UNIX may have been made due to limitations of 16 bit address space, on a swapping architecture, rather than demand paging; having seperate processes mean the kernel automatically multi-tasks these components on a multi-CPU system. The drawback may be that upgrading libc is more fragile, without a statically linked toolchain available as a last resort. Keeping init(8) simple, as Scott suggests above looks to me like a good design decision. > I suppose in the extreme case, anytime any process wishes to run > another process as root, init could do it (via an IPC request of > course); that way there is just one place where escalation of > privileges is handled. But I'm sure you can think of some arguments > against that (it sure isn't very traditional). You look like you'll be interested in Policy Kit at Freedesktop.org which is specifically targetted at fine grained privilege escalation. The problem is that "running another process as root" is doable by setuid bit, but security wonks would like to enable minimum capability required, to follow principal of least privilege. Moving the access control mechanism into user space, rather than kernel, could easily expose race conditions; so it looks like quite a tough project to me, which small mistakes could jeopardise gains made in other areas. > > Can save snapshots of the system status ... And why is this useful? If > > you want to snapshot your system, hibernate it. Hibernate / resume, makes lots of assumptions about state of hardware, is not usable where system will be rebooted into different OS, or not resumed on next boot, so I presume the "snapshot feature" is actually more akin to session idea in desktops which attempt to restart programs where they left off. > Maybe it would be nice to define runlevels by example rather than by > editing code. E.g. start the services that you want to be running, > kill everything you don't, and then generate a runlevel definition > based on the current system state. But that can be done by an > external program easily enough. Not sure if it's even good idea... > just an idea that's all. Superficially that sounds attractive, but having thought about it, I think that wouldn't work too well in practice. The reason is that during lifetime of system, you tend to add new daemons, possibly also change the ones you run. With this model, the admin would have to re-create the system state to redefine the snapshot of the system state, which would be an error prone process. Daemons that are in packages, with knowledge of their dependencies, for example "nameservice", can be added without reducing availability of system. They also may run, when lower level daemons required even during system maintenance, would be added or altered, so that way you're not forcing the admin to keep track of very many server processes. As Upstart is specified to understand dependancies and dynamically decide start up order, of these processes, it would be a huge step back, to impose that knowledge on the admin, and it would be beyond most end users. -- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
