[04:01] 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:03] what should I be trying? (there isn't a limit on the number of conditions, is there?) [04:03] the job in question doesn't ever get mentioned in verbose output. [08:13] geofft: is the job valid? e.g. status $jobname [08:14] geofft: and to start that job you need to do "initctl emit a; ... b; ... c; ... d; ... e;" or "initctl emit f" [08:14] 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:22] xnox: lemme reboot this VM, one sec, but I believe status said stopped/waiting [08:23] and it never started, from boot [08:25] geofft: then all events have not fired. [08:26] then why did my test jobs all run? [08:26] geofft: and/or the events are mistyped or misnamed. [08:26] well, it also seems to work one in several boots... [08:26] is it possible for events to fire too early / in the wrong order? [08:31] I am pretty confident I typed the test jobs the same way they are listed in the actual job [08:31] like, on the dumb questions front, is it known that having five "and"s works? is there some internal limit? [08:31] or can I ask upstart which condition it thinks didn't fire? [08:38] 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:39] geofft: can you please list actual config? [08:40] geofft: echo start on ((a and b and c and d and e) or f) | sudo tee /etc/init/foo.conf [08:40] sure, I can pastebin or something, one sec [08:40] geofft: for event in a b c d e; do sudo initctl emit --no-wait $event; done [08:40] geofft: sudo status foo [08:40] works. [08:41] xnox: yes, I can get it to work if I manually emit d. [08:42] 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] the only change the override does is adding "and e" ("and stopped baremetal-earlyauth"). [08:48] (and that job is successfully running and then stopping) [08:49] geofft: task & expect stop don't make sense. [08:50] geofft: on boot what's the "status baremetal-earlyauth" ? is that process simply stopped and that's it? [08:50] geofft: also task doesn't make sense and to key on "stopped baremetal-earlyauth" [08:51] hm, sure, but I added task later as part of debugging, and it was broken before that, too. [08:51] I can pull it back out [08:51] 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] it does use SIGSTOP for readiness (there's something else that waits for "started baremetal-earlyauth") [08:51] since for tasks, started is emited after all process quit. [08:52] 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:53] if there is something else, it may be blocking for stopped to be emitted. [08:53] ... [08:53] hm, that doesn't match my reading of http://upstart.ubuntu.com/cookbook/#task ? am I misreading it? [08:54] baremetal-earlyauth is a short-running program that (possibly) prompts you for a password at plymouth [08:54] 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:55] (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:59] taking out "task", same behavior, and `status baremetal-earlyauth` is stop/waiting. [10:00] xnox: am I misreading the upstart cookbook docs about when tasks emit started and stopped? [21:08] 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. === xnox is now known as xnox_ [21:21] 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] '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 === xnox_ is now known as Eisbrecher === Eisbrecher is now known as Eisbrecher_xnox