[05:57] hi.. i have serveral upstart jobs which run in turn on startup.. one of them is pretty basic, consisting mainly of a single exec in script tags [05:57] when it is first started by upstart, the program it runs is left running, and the upstart script goes into a waiting mode, when it should be running... [05:58] when i then exit the application, upstart doesn't continue to do the various things it should [05:58] if i start the job manually, it all seems to work [05:58] any ideas what I am doing wrong? [09:58] iamthelostboy: it's likely that the process actually doesn't stay running [09:58] and instead turns itself into a daemon [09:58] do you have the output of the "start" command for that job? [12:05] I wish the test suite wouldn't take 35 minutes to complete when run under valgrind [15:08] I have a bit of a question for jobs. The event system makes sense for starting a job, but what about stopping? Do we have to make two jobs per 'application' (Start and Stop of the init scripts) [15:11] Moncader: um... could you try to rephrase that? [15:11] Moncader: Upstart jobs are written in a declarative form, not an imperative form [15:12] ie. instead of describing how to start and stop the service, you instead describe what the service *is* [15:12] the ability to stop that service is inherently built in to Upstart [15:12] (send SIGTERM, wait, then SIGKILL) [15:13] Hmm, this is true for running exec stanzas or scripts that run a single application. [15:13] However, what about the case of say, an initial system startup script, and then the equivalent shutdown? [15:15] Moncader: usually the wrong way to do it. However pre-start/post-stop etc are the way to do that [15:17] Moncader: can you give an example [15:17] do you mean like having a job to mean "mount/unmount filesystems" - where on the way up it mounts them, and on the way down it unmounts them? [15:18] Well. Currently, I'm building yet another Linux from Scratch system. This time I thought I'd use a different init system. So I'm going for a 100% upstart system, trying to get rid of the whole rc.d structure. [15:18] To do that, there were a couple scripts (rcsysinit, rc.local) that do things only on startup. [15:18] sure, but bear in mind that Upstart isn't just a "better sysvinit" - it's quite different [15:18] the "only do things on startup" case are interesting [15:18] the best way to do those are as tasks [15:18] e.g. [15:18] task [15:18] script [15:18] .... [15:18] end script [15:19] starting a task will block until it is finished, not until it is running [15:19] so "start rc.local" won't return until rc.local is done [15:19] mm. Guess so. Just that upstart is supposed to be a full replacement for sysinitv, so I was wondering what to do in that case. [15:19] Alright [15:19] or if you had "start on starting foo" in rc.local, foo would not be started until rc.local was *finished* [15:19] it's a full replacement for sysvinit, not sysv-rc [15:19] many people confuse the two [15:20] Ah, I see [15:20] Upstart can run the sysv-rc script (usually /etc/init.d/rc) just as well as sysvinit can [15:20] but it doesn't deal with /etc/rc2.d and stuff, you run the sysv-rc script from Upstart to do that [15:20] Yes, which is of course what most distros are doing now. [15:20] another common pattern in Upstart is that the job implies a state [15:21] for example, "mountfs" could be always "running" when the filesystems are mounted [15:21] start mountfs would mount the filesystems [15:21] and stop mountfs would *unmount* them [15:21] the way to do that in Upstart is using pre-start and post-stop without a primary exec/script [15:21] e.g. [15:21] pre-start exec mount -a [15:21] post-stop exec umount -a [15:21] that's valid, even though there's no "exec"/"script" on its own [15:21] Heh, interesting way to do it. [15:22] Upstart will claim it's running with no process [15:22] "start on starting mountfs" is still valid - will be run before mount [15:22] "start on started mountfs" is still valid - will be run after mount (thus when the filesystems are up) [15:22] "start on stopping mountfs" is still valid - will be run before umount [15:22] "start on stopped mountfs" is still valid - will be run after umount (thus when the filesystems are gone) [15:22] I see. Thank you. [15:23] you might realise that it's trivial to wrap initscripts like this ;) [15:23] pre-start exec /etc/init.d/foo start [15:23] post-stop exec /etc/init.d/foo stop [15:23] Yes :) But for fun I'm trying to get rid of init scripts :) [15:23] Upstart won't know the pid and suchlike while it's running, of course, but it's "close enough" for most people [15:24] - and I have a solution for that too :p [15:24] Heh, of course :) [16:06] my life is made so much easier by tests/expected :) [16:06] TEST_EXPECTED_STR (str, "foo.c"); [16:06] compares the contents of str against the contents of tests/expected/foo.c [16:07] and also TEST_EXPECTED_FILE (fp, "foo.c"); [16:07] Neat [17:05] Keybuk: just some small nit [17:05] the copyright assignment pdf linked on http://upstart.ubuntu.com/wiki/CopyrightAssignment [17:05] has a wrong url in the pdf document [17:06] Clicking on [17:06] http:// [17:06] canonical.com/contributors [17:06] sends you to http://www.canonical.com/contributor (note the missing 's') [17:06] mbiebl: I'll let Amanda know [17:08] Keybuk: is this copyrigth assignment bound to the email address I use for signing? [17:08] thanks [17:08] mbiebl: I'll tend to use the e-mail address for the ChangeLog [17:08] unless you want me to use a different one [17:09] Keybuk: my launchpad account uses a gmail address, but I don't use that address for signing emails [17:11] the mail doesn't have to be signed AIUI [17:11] GPG signed, that is [17:11] the text itself is a signature under UK law [17:12] Keybuk: I was just wondering if I send a patch using a different email address than the one that was used for signing the copyright assignment [17:13] that's ok ;) [17:14] hm [17:15] how do you know then that the persons behind mbiebl@gmail.com and say biebl@debian.org are actually the same person? [17:19] Maybe I'm just seeing a problem where there is none ;-) [17:21] mbiebl: I can always ask if unsure ;) [17:22] which e-mail address would you like in ChangeLog btw? [17:23] I don't really mind ;-) [17:23] I suspect you're just thinking from a Debian point of view [17:23] where everything has to be signed, and everything has to have a trust path [17:23] and all 'i's must be dotted and all 't's crossed [17:24] Canonical's Contributor Agreement was written by a lawyer [17:24] they see through games like "aha! but I sent it from a different e-mail address" [17:24] :-) [17:24] plus it's not an assignment of copyright per se [17:25] it's a copyright licence [17:25] Keybuk: I've polished up the state transfer patch, but I'm not entirely sure what sort of testing I should do on it. Its really wired in to everything else, it could end up comprising a system test depending on how much fudging we do. [17:26] sadmac2: the code should at least be covered under tests/ [17:26] Keybuk: if that's the water mark, then I'll have it done soon. [17:27] Its only 2 functions, so just poking them doesn't take much time [17:27] it's basically so we can prove it works [17:27] and isn't broken by future changes [18:38] Keybuk: is there a reason why upstart is still registered as GPLv3 project on the launchpad page? === notting_ is now known as notting [19:44] mbiebl: forgot to change it [19:45] fixed === notting_ is now known as notting [23:37] I have a network file system that I boot a large number of server off of, I would like to be able to run a getty on ttyS1 on those servers which have an appropriate device \ [23:37] however, on some servers, getty complains of a input/output error on ttyS1 and is restarted by upstart after quitting, is there any way to prevent upstart from continuously restarting the getty? [23:38] (alternatively, can someone point me to the documentation on the format of the files in /etc/event.d) [23:46] ah, found it, http://upstart.ubuntu.com/wiki/Stanzas , thanks anyway