| geofft | hi folks! I'm trying to debug why a "start on ((a and b and c and d and e) or f)" job isn't starting. I made test jobs with "start on a" through "start on e", and they all run. | 04:01 |
|---|---|---|
| geofft | what should I be trying? (there isn't a limit on the number of conditions, is there?) | 04:03 |
| geofft | the job in question doesn't ever get mentioned in verbose output. | 04:03 |
| xnox | geofft: is the job valid? e.g. status $jobname | 08:13 |
| xnox | geofft: and to start that job you need to do "initctl emit a; ... b; ... c; ... d; ... e;" or "initctl emit f" | 08:14 |
| xnox | geofft: if the job is stopped, the full a-e set of events needs to be re-emitted. or f event needs to be emitted. | 08:14 |
| geofft | xnox: lemme reboot this VM, one sec, but I believe status said stopped/waiting | 08:22 |
| geofft | and it never started, from boot | 08:23 |
| xnox | geofft: then all events have not fired. | 08:25 |
| geofft | then why did my test jobs all run? | 08:26 |
| xnox | geofft: and/or the events are mistyped or misnamed. | 08:26 |
| geofft | well, it also seems to work one in several boots... | 08:26 |
| geofft | is it possible for events to fire too early / in the wrong order? | 08:26 |
| geofft | I am pretty confident I typed the test jobs the same way they are listed in the actual job | 08:31 |
| geofft | like, on the dumb questions front, is it known that having five "and"s works? is there some internal limit? | 08:31 |
| geofft | or can I ask upstart which condition it thinks didn't fire? | 08:31 |
| geofft | hrrrm, I wonder if it's a misparse given that d is an instanced job, and it all works fine if "and e" isn't around. | 08:38 |
| xnox | geofft: can you please list actual config? | 08:39 |
| xnox | geofft: echo start on ((a and b and c and d and e) or f) | sudo tee /etc/init/foo.conf | 08:40 |
| geofft | sure, I can pastebin or something, one sec | 08:40 |
| xnox | geofft: for event in a b c d e; do sudo initctl emit --no-wait $event; done | 08:40 |
| xnox | geofft: sudo status foo | 08:40 |
| xnox | works. | 08:40 |
| geofft | xnox: yes, I can get it to work if I manually emit d. | 08:41 |
| geofft | my local changes are http://paste.debian.net/108646/ , the rest is all from Trusty (which I can pastebin if that's useful) | 08:42 |
| geofft | the only change the override does is adding "and e" ("and stopped baremetal-earlyauth"). | 08:42 |
| geofft | (and that job is successfully running and then stopping) | 08:48 |
| xnox | geofft: task & expect stop don't make sense. | 08:49 |
| xnox | geofft: on boot what's the "status baremetal-earlyauth" ? is that process simply stopped and that's it? | 08:50 |
| xnox | geofft: also task doesn't make sense and to key on "stopped baremetal-earlyauth" | 08:50 |
| geofft | hm, sure, but I added task later as part of debugging, and it was broken before that, too. | 08:51 |
| geofft | I can pull it back out | 08:51 |
| xnox | geofft: i think you want "task", delete "expect stop" (unless baremetal-earlyauth actually uses SIGSTOP), and in the lightdm.override you want "and started baremetal-earlyauth" | 08:51 |
| geofft | it does use SIGSTOP for readiness (there's something else that waits for "started baremetal-earlyauth") | 08:51 |
| xnox | since for tasks, started is emited after all process quit. | 08:51 |
| xnox | there is no distinction between started & stopped for tasks. Task only emit "started" after all processes quit. That's how "tasks" are different from normal/regular jobs. | 08:52 |
| xnox | if there is something else, it may be blocking for stopped to be emitted. | 08:53 |
| xnox | ... | 08:53 |
| geofft | hm, that doesn't match my reading of http://upstart.ubuntu.com/cookbook/#task ? am I misreading it? | 08:53 |
| geofft | baremetal-earlyauth is a short-running program that (possibly) prompts you for a password at plymouth | 08:54 |
| geofft | and I care both about readiness, since other things communicate with it, and exit, since I don't want to start lightdm until it's done. | 08:54 |
| geofft | (looking again, I take that back, there isn't something that waits for "started baremetal-earlyauth", but probably I don't want task, anyway.) | 08:55 |
| geofft | taking out "task", same behavior, and `status baremetal-earlyauth` is stop/waiting. | 08:59 |
| geofft | xnox: am I misreading the upstart cookbook docs about when tasks emit started and stopped? | 10:00 |
| paintedbicycle | Having trouble with upstart on ubuntu with nodejs. I start the app with user called 'deploy', but app doesn't have permission to write to disk even though all files are owned by deploy. When I log into ubuntu as deploy and start app, app can write fine. Tried using setuid, asked on serverfault, still no luck. | 21:08 |
| === xnox is now known as xnox_ | ||
| paintedbicycle | To follow up, at first when running "sudo -u 'usernane' ..." the sudo process wouldn't go away, so I got an answer here (http://serverfault.com/questions/608240/upstart-why-two-processes-when-running-as-a-different-user/609194) to allow the sudo process to go away and just leave me with my app running as the 'deploy' user I want. Verified that with 'ps aux'. However, when I use the app, the permissions are definitely not | 21:21 |
| paintedbicycle | 'deploy' as it can't do anything. None of the tutorial that use setuid, etc seem to be any different from one another and are mostly out of date | 21:21 |
| === xnox_ is now known as Eisbrecher | ||
| === Eisbrecher is now known as Eisbrecher_xnox | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!