Hi Evan, On 18/06/11 17:50, Evan Huus wrote: >> A very quick sketch solution would be allowing multiple >> "job.override.overriding_program_or_user" files as override files. If two >> such files try and override the same stanza, upstart throws a big fat >> warning and completely ignores all stanzas from all override files >> (assumption that the default job config is sane without any overrides?) >> >> Still, this is basically a separate issue, to be dealt with in another >> thread sometime. > > In retrospect, this seems like a bad idea :) Yes - we could end up with a lot of cruft in /etc/init/ from various programs and scripts fighting it out :-)
And as mentioned in my original mail, we need to keep the inotify watch limit in mind: if we allowed the format you mentioned, you've suddenly got a 1-to-many mapping for number of conf files / job. > The problem is more that it's difficult for automated scripts to > modify conf or override files at all without being really clever. Agreed. > Sure, it's easy to hard-code a string to append to the end of a file, > but there is no easy way that I'm aware of for another program to > intelligently inspect an upstart or override file and make decisions > based on that without writing its own parser. Well, there is "initctl show-config" but it isn't deciphering all the stanzas: only start on, stop on and emits. Added to which, the contents of the underlying files may change between invocations to show-config. > > One solution would be to split the parse_job bits out into a separate > libupstart-jobfile or similar and add a 'save' or 'write' method. This is an interesting idea. I had a tangentially-related discussion with Barry Warsaw at UDS who suggested a "libupstart" library with bindings for languages such as Python (obviously of interest to Barry :-) I think this whole idea needs further exploration and discussion. A few thoughts which spring to mind: 1) If Upstart itself used such a library to read and parse files, we would need to ensure that it could not be blocked when attempting to read a file to avoid locking up init. 2) It would make sense to expose such functionality over D-Bus. However, the library cannot make write requests back to Upstart itself, since as discussed we are generally against the idea of init/initctl writing to /etc. But that implies another D-Bus server (daemon). Yet, such a new server would be providing Upstart functionality...? What is convenient about such a library is that it would still work for chroot sessions and could be made to work for user sessions too. > Theoretically a program should be able to link with the lib, call > parse_jobfile(name), modify the returned object, and then save it, > with the library guaranteeing that the written job file is at least > grammatically sane. A dumb cli frontend would make it easy for scripts > and users to do the same. Right. > > Back to how this applies to the original comment: SysV didn't prevent > automated scripts from overriding user choices in this fashion either, > it just made it easy for scripts to do what they wanted without > *accidentally* overriding user choices. Hopefully a libupstart-jobfile > would solve that problem. Indeed. At some level, we'd need policy to protect the system. > Given some sort of solution to the above, then it is clearly no longer > necessary for separate job.limit files or a separate /etc/init.limits > or anything along those lines - it should be safe and easy for > multiple scripts/users to put everything they want into one > job.override file. Yes, although I do think that if we go the libupstart route, the dumb cli frontend should write a log somewhere showing which app/process made which change. The question then becomes what stanza should be > used, and how it should be handled. While I still prefer the term > 'disable' to 'limit', everything else that's already been proposed > makes good sense to me. > > Cheers, > Evan -- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
