| sykopomp | hi, a coworker is having issues with conf file reloading. When he edits an upstart he's working on and checks the loaded config, it seems to stay the same. | 15:14 |
|---|---|---|
| sykopomp | is there anything special that needs to be done? reload-config doesn't seem to do the trick, either. | 15:14 |
| sykopomp | rebooting worked, but that's not really practical :) | 15:15 |
| SpamapS | sykopomp: are you on a live-cd/live-usb by any chance? | 16:51 |
| sykopomp | no | 16:51 |
| SpamapS | sykopomp: ok. Well the job files should be reloaded using inotify. If not, you can just do 'initctl reload-configuration' to reload them all.. | 16:51 |
| SpamapS | sykopomp: note that 'restart $jobname' does not actually use the new configuration for $jobname, you have to stop/start | 16:52 |
| dluna | SpamapS: So if there are issues with stopping a job, the new config will not load? | 16:54 |
| dluna | > sudo stop s-core | 16:56 |
| dluna | stop: Job has already been stopped: s-core | 16:56 |
| dluna | sudo status s-core | 16:56 |
| dluna | s-core stop/killed, process 26228 | 16:56 |
| dluna | there is no process 26228. | 16:57 |
| SpamapS | dluna: ahh, the "expect loses track of X pid" bug | 16:58 |
| SpamapS | dluna: Your only recourse is to "resurrect" 26228 by exhausting pid space | 16:58 |
| SpamapS | dluna: http://paste.ubuntu.com/1151031/ that works | 16:59 |
| dluna | Thanks. | 17:01 |
| dluna | That was not the answer I was hoping for, but I'm very happy that you told me. | 17:01 |
| SpamapS | dluna: bug 406397 for your pleasure ;) | 17:02 |
| SpamapS | hm, bot lagged? | 17:02 |
| SpamapS | dluna: http://pad.lv/406397 | 17:03 |
| dluna | Yeah. I'm reading it. | 17:06 |
| dluna | Sucks! | 17:06 |
| dluna | That bug is *three years old*. | 17:08 |
| SpamapS | dluna: https://bugs.launchpad.net/upstart .. we're always grateful for bugfix help :) | 17:08 |
| dluna | yeah. I sent two for the documentation already. | 17:08 |
| SpamapS | that bug, btw, by far has the highest "heat" of any bug | 17:08 |
| SpamapS | affects 48 | 17:09 |
| dluna | I'll add myself to it. | 17:09 |
| SpamapS | I'd raise the priority myself but I'm not on the bug supervisor team for upstart | 17:09 |
| SpamapS | jodh: ^^ perhaps this would be a good next target for bug fixing http://pad.lv/406397 | 17:09 |
| dluna | btw. Does anyone know how upstart detects the forked processes? (I'm asking since using the strace/grep fork|clone test recommended at 6.11.4 in docs gives me a count of 34 (I'm using Erlang and just starting 'erl' yields 14 using that test (lots of threads))) | 17:31 |
| SpamapS | dluna: ptrace | 17:32 |
| SpamapS | dluna: it doesn't count threads as forks | 17:32 |
| dluna | Good. | 17:33 |
| SpamapS | dluna: another option is just to keep your program in the foreground | 17:56 |
| SpamapS | which, frankly, I prefer | 17:56 |
| SpamapS | unless you have to depend on the 'started' event .. I think the 'expect fork' thing is of limited value for general purpose services. Seems about 50/50 whether or not things fork to signal that they're "ready" | 17:57 |
| dluna | Well. I haven't researched what the actual start sequence is doing. I need to start our system at machine start, so it needs to be in the background (and then there is an 'attach' feature to connect to the shell). | 18:03 |
| SpamapS | dluna: if it has a mechanism to not "daemonize" (meaning it just starts up and keeps running, and doesn't fork/exit at start up) that will relieve you of needing expect fork | 18:11 |
| SpamapS | dluna: its still "in the background" in the sense that it is not attached to a terminal | 18:11 |
| dluna | True. I'm fairly certain that there is at least one fork in there. Not my code unfortunately... | 18:16 |
| SpamapS | dluna: its not so much "is there a fork" but "is this the fork that produces the parent process that runs forever" | 18:21 |
| dluna | true | 18:59 |
| dluna | SpamapS: anyway. Thank you. Immensely helpful. | 19:01 |
| SpamapS | dluna: any time | 19:11 |
| dluna | Is there any way of talking about more than 2 execs in 'expect'? Or for that matter specify the pid to be tracked (I have access to it, or can at least get access by using pgrep or looking in some logs). | 19:48 |
| santinod | If I disable a service job (to prevent it from running at startup) by means of the ".override" file, I lose the ability to run it via the /etc/init.d script (as required e.g. by heartbeat). Is there a workaround? | 20:41 |
| SpamapS | dluna: you can just not use upstart's pid tracking by running the daemon in pre-start and killing it in post-stop... | 21:11 |
| SpamapS | dluna: you still get the events, just not tight control over the process | 21:12 |
| SpamapS | santinod: are you sure you disable it from use by /etc/init.d ? | 21:12 |
| santinod | If I create the .override file, the service is not run at startup (which is correct), but cannot be run by its /etc/init.d/ script either | 21:15 |
| santinod | "/etc/init.d/mysql start" does not run mysql any more | 21:16 |
| SpamapS | santinod: no error is printed? | 21:23 |
| SpamapS | santinod: I'm looking at the quantal version of /lib/init/upstart-job (which is what /etc/init.d/mysql is symlinked to) and it doesn't seem to check for manual | 21:24 |
| SpamapS | ahh never mind | 21:25 |
| SpamapS | it checks using show-config | 21:25 |
| santinod | initctl show-config -e "$JOB"|grep -q '^ start on' || DISABLED=1 | 21:25 |
| SpamapS | yeah | 21:25 |
| SpamapS | I'm not even sure why we did that | 21:25 |
| santinod | so it sets DISABLED=1 and later checks for it | 21:25 |
| SpamapS | santinod: well you can get around this (lame as it is) by using 'start on never' instead of 'manual' | 21:26 |
| SpamapS | because then you'll still have a start on | 21:26 |
| santinod | I see | 21:28 |
| santinod | well, I wanted to preserve as much as possible the integrity of the distro startup scripts (in this case Ubuntu) | 21:29 |
| SpamapS | santinod: you can put 'start on never' in the .override | 21:29 |
| SpamapS | santinod: you can rewrite the whole upstart job in there :) | 21:29 |
| santinod | this sounds interesting | 21:30 |
| santinod | hmm, "start on never" in the .override seemed to do the trick | 21:31 |
| santinod | thanks a lot! | 21:32 |
| SpamapS | santinod: one is glad to be of service | 21:34 |
| dluna | SpamapS: thanks. I'll do that. That solves all of my problems I think. | 21:41 |
| SpamapS | dluna: just means respawn won't work | 21:47 |
| SpamapS | dluna: nor will the 'reload' command | 21:48 |
| dluna | ah. Of course. | 21:54 |
| dluna | reload won't work anyway, and I can use (erlang) heart to do my restarts for me. | 21:55 |
| SpamapS | awesome | 21:59 |
| JoeGaudet | Hey guys, wondering if anyone can point me at the right place to figure out how to let a non root user call stop/start on a particular conf file ? | 23:49 |
| JoeGaudet | Maybe what I want is User Jobs ? | 23:51 |
| SpamapS | JoeGaudet: I think you want the dbus ACLs | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!