On Tue, Jun 21, 2011 at 9:31 AM, James Hunt <[email protected]> wrote: > 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.
I'm not too familiar with the intricacies of file IO here. How weird would it be for user-space authors if the library provided only init-safe file access? How hard/complex would it be for the library to provide both types of IO? > 2) It would make sense to expose such functionality over D-Bus. Why? The two primary use cases I was envisioning for this was within upstart itself, where it probably makes the most sense to link it in statically at compile time, and for debian pre/post-install/remove scripts, which would be using the dumb cli frontend. Sure, exposing it over D-Bus would be nice for other programs too lazy to link it in themselves, but it isn't actually necessary, and it comes with a whole slew of interesting side-problems as you've already mentioned. > 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...? Confused slightly here. If we link in the library, then it's just a matter of making sure we don't call the library's 'write' or 'save' method anywhere within upstart, no? > 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. My initial thought was even simpler than that: the library should just take a path name (/etc/init or ~/.init or whatever) and a job name and not care about chroots or anything complicated like that. It could even be used for manipulating job files in a temporary working directory this way, or on a partition mounted somewhere else on the filesystem. The library shouldn't care if it's working in /etc/init or not. >> 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. tl;dr - I agree Massive tangent: It should be specifiable (in /etc/init.conf) a 'system happy' job (such as perhaps gdm or the new display-manager alias) such that upstart knows the system has booted relatively successfully if that job is running successfully. Whenever the system boots successfully, upstart (or a related daemon) copies the contents of /etc/init/ to /etc/init.known_good/. Whenever the system fails to boot successfully (No new jobs started within timer limit even though target happy job not running?) upstart reboots (re-execs?) and boots with /etc/init.known_good/ instead. >> 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. Agreed Cheers, Evan -- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
