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