| brendand | jodh, we want to run our test tool as soon as the system is ready to be tested. what that actually means may need discussion. i don't know that much about upstart | 10:26 |
|---|---|---|
| jodh | brendand: ok, well you need to know what environment your test tool needs to run in. | 10:27 |
| jodh | brendand: 'start on runlevel [2345]' is generally appropriate for jobs that need to run when disks are mounted and networks are up. | 10:27 |
| brendand | jodh, we do - but how to express that in upstart terms is beyond me at the moment | 10:27 |
| jodh | brendand: so what does your test tool need before it can run? | 10:28 |
| brendand | jodh, the best way to describe it would be to say that we should start testing when all initialisation that's going to happen has happened | 10:28 |
| jodh | brendand: what does the test tool test? | 10:29 |
| brendand | jodh, well we're testing hardware so all services that interact with hardware need to be started | 10:29 |
| jodh | brendand: can you give examples of such h/w services that you care about? | 10:29 |
| brendand | networking | 10:29 |
| brendand | usb | 10:29 |
| zyga | jodh: we talk to network manager, udisks, poke udev | 10:30 |
| brendand | zyga, actually on servers we don't touch NM | 10:30 |
| zyga | brendand: perhaps this also implies our jobs should be able to depend on upstart stuff being started? that would remove the requirement from plainbox itself and offset it to other parts of the system | 10:30 |
| brendand | jodh, on desktop systems we are just using xdg autostart to start after login | 10:31 |
| brendand | jodh, so we're thinking only about servers here | 10:31 |
| zyga | brendand: we could perhaps use upstart for that as well, without user sessions (jodh: we need to support precise +) | 10:31 |
| jodh | brendand: I'd go for the runlevel 'start on' then since nm isn't going to be available on the server. | 10:36 |
| zyga | jodh: meta-question, do you think backporting current upstart to precise would be a good idea? | 10:37 |
| brendand | jodh, http://upstart.ubuntu.com/cookbook/#normal-start seems to imply that using the runlevel start on would mean that you are okay with the service starting without a valid network interface | 10:37 |
| jodh | brendand: please just try the runlevel start on. I'll tweak the cookbook when I'm less busy ;) | 10:39 |
| * brendand is reading https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/701576 | 10:39 | |
| jodh | zyga: why? | 10:39 |
| zyga | jodh: so that stuff that targets 12.04 can take advantage of new features and can rely on stuff that upstart is good at | 10:39 |
| jodh | zyga: doesn't that argument apply to most packages in Ubuntu though? | 10:41 |
| zyga | jodh: yes but web apps typically sidestep normal packaging already | 10:42 |
| zyga | jodh: yet depend on upstart for getting started | 10:42 |
| jodh | zyga: upstart in precise works perfectly well. I don't understand your argument. | 10:43 |
| zyga | jodh: perhaps I miss something, let me explain that | 10:44 |
| zyga | jodh: I was looking for setgit/setuid but apparently those are in precise by now | 10:45 |
| zyga | jodh: I must have confused that with lucid | 10:45 |
| zyga | setgid | 10:46 |
| jodh | zyga: ok. You can compare 'rmadison upstart' with http://upstart.ubuntu.com/cookbook/#stanzas-by-category | 10:49 |
| fabiant7t | Is it possible for a service to stop itself and prevent further respawns for the current upstart session? | 14:39 |
| fabiant7t | My use case is to shut down a client service whose server (another system) rejected communication. The client exits but respawns immediately due to upstart. | 14:41 |
| xnox | fabiant7t: respawn can have limits, such that it will stop respawning. | 14:46 |
| fabiant7t | xnox: thx! I'll try to add a respawn limit to the upstart job | 15:01 |
| xnox | fabiant7t: http://upstart.ubuntu.com/cookbook/#respawn-limit | 15:04 |
| fabiant7t | xbox: Jap, I'm reading through it, just need to find the right place to apply it on saltstacks generic upstart job script (http://dpaste.com/1052456/) | 15:05 |
| SpamapS | fabiant7t: if the service exits with a normal exit, no respawn will ocurr | 15:16 |
| SpamapS | fabiant7t: so just exit(0) | 15:16 |
| fabiant7t | SpamapS: I tested that with sys.exit(0) in python, but it got respawned | 15:17 |
| SpamapS | fabiant7t: something went wrong then | 15:17 |
| SpamapS | fabiant7t: is it being run by a wrapper script that maybe doesn't exit cleanly? | 15:17 |
| fabiant7t | SpamapS: As far as I can tell (and read in the logs), it did exit property with a return code 0 | 15:19 |
| fabiant7t | SpamapS: I'm trying to fix that issue here, btw: https://github.com/saltstack/salt/issues/4411 | 15:20 |
| SpamapS | fabiant7t: oh I misunderstood actually | 15:20 |
| SpamapS | only tasks can exit 0 to avoid respawn | 15:20 |
| SpamapS | fabiant7t: to make non-tasks behave the same way you have to add 'normal exit 0' | 15:21 |
| fabiant7t | SpamapS: It's a system service, and it's running into a deadlock right now | 15:21 |
| fabiant7t | SpamapS: to this script? http://dpaste.com/1052456/ | 15:22 |
| fabiant7t | I am pretty unfamiliar with upstart and the startup scripts, unfortunately :( | 15:23 |
| SpamapS | fabiant7t: oh thats a sysvinit. Wha? | 15:23 |
| fabiant7t | obviously it got automatically rewritten to upstart | 15:23 |
| SpamapS | fabiant7t: wait no, ignore that script | 15:24 |
| SpamapS | fabiant7t: /etc/init/$that_scripts_name.conf | 15:24 |
| fabiant7t | SpamapS: aaah, got it | 15:25 |
| fabiant7t | SpamapS: That fixes the loop, thanks a lot! | 15:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!