[08:38] hi, I have a service that's choking when the system wildly changes the datetime.. and this happens because my board has no rtc backup battery.. my goal is to just restart that service once the date has been set by ntpdate.. is there an easy way to do this? I'm trying to read upstart docs but nothing useful for me so far [08:44] I thought maybe "start on ntpdate stop" but I think that's triggered by ifup.d not upstart? === vf5761 is now known as hidgw === hidgw is now known as dgw === vf5761 is now known as hidgw === vf5761 is now known as hidgw [19:36] so I started a custom job and it looks like it got stuck in pre-start... so I eventually ctrl-c and stop hangs as well in the same way. status says "stop/starting". how do I recover from this? [19:36] there don't appear to be any PIDs I can kill :-) [20:09] is there not a way to tell upstart to just reset all of its state on a job? [20:10] raydeo: Does or did the job use an “expect” stanza? [20:11] no [20:11] the job doesn't do anything, it just has pre-start and post-stop [20:12] I've since changed the script, but upstart doesn't appear to care about my changes while it's in this "stop/starting" state [20:13] ion: the other day I ran into the "expect" issue and had to run a script to create/kill the PID that upstart thought was there [20:14] however this script has no expect/exec/script stanza for me to do that with [20:14] Ok. I haven’t encountered that issue then. [20:15] this really isn't a good time to reboot.. can't believe there isn't a way to bounce or force the state of a single job to get upstart back in line [22:25] hey there. Is there a way to do custom commands such as "initctl reload [target]"? [22:32] styol: reload command simply sends a SIGHUP or other signal specified by "reload signal" stanza. [22:33] styol: if you want custom commands, you should create a new job, which specifies "task" and do anything you like between "script .... end script" as a bonus you can accept variables from events and command line. [22:33] styol: e.g. start dotask FORCE=yes [22:34] styol: there is no generic support for custom commands. What do you want to achieve with your custom command? =) [22:34] xnox: oh! didn't realize that was a stanza.. your approach does make sense and should work. I appreciate it [22:35] xnox: while thinking about it, I actually just realized that the start stanza will actually do the same task that i was looking to do a custom command for *facepalm*. It will start as well as reload the configuration file (if already running) [22:37] xnox: since you seem awesome and are around, perhaps one more question ;) related but unrelated, after what run level does /etc/rc.local run? There is a NAS being mounted there and I think, but am not sure, that it is occurring after the upstart job which relies on the NAS being mounted. Guess that should be changed to an upstart job also that has the dependency thing. "start on start [init]" correct? [22:37] *start on started [22:40] I see /etc/rc2.d/S99local which is a symlink to /etc/rc.local -- though it also exists in rc3 - rc5 as well [22:53] styol: one should not use rc.local [22:54] styol: networked file-systems should be declared / handled by rcS level and/or upstart jobs - mountall. That way upon mounting NAS, filesystem event would be emitted for that mount point and other upstart jobs can start on remote-filesystems [22:56] styol: as a workaround you can do [22:57] styol: after NAS is done, that script should do $ initctl emit nas-is-up [22:57] styol: and then your upstart jobs can be "start on nas-is-up" [22:59] xnox: yeah working with some legacy, but that sounds like the appropriate solution indeed. Is the `start on start [app]` notation just to depend on another upstart job being started while emit is for a specific event that you can `start on [event]`? [23:00] doh, again -- `start on started [app]` [23:01] oh and there isn't any native way to make an upstart job a CLI command, correct? Just need to create some sort of wrapper bash script or something that does `initctl $action app`? [23:02] styol: i don't understand what you mean. "started" is one of the system events which are emitted by upstart itself for upstart jobs only. [23:03] styol: see $ man 7 upstart-events [23:03] on your system (or manpage on the web for the same version/release as your system) [23:04] styol: upstart jobs are declarative, and the actions that initctl can do are predetermined e.g. start, stop, restart, reload, status etc.... all of them are internal to upstart [23:04] styol: see job filecycle in $ man 8 init [23:05] styol: but jobs can can pre-start/post-start pre-stop/post-stop where you can run arbitrary shell scripts to e.g. bail starting a job, block on staring some other job, and do anything you like. [23:06] styol: see http://upstart.ubuntu.com/cookbook/ for best practices it explains a lot of things one can do, to achieve practically anything =) [23:13] xnox: thank you so much, I will checkout the referenced manuals and cookbook. it is much appreciated. [23:13] one thing is that it seems I'm rocking 0.6.5 by default on centos 6.3, though I'm guessing it can be upgraded [23:14] noticed the discrepancy when I attempted to utilize `console log` [23:17] styol: yeah, use manpages provided with your distribution to check that things you want to use, are in-fact available. [23:17] styol: e.g. man 5 init [23:18] roger.. just out of curiosity, what are the different numbers for? [23:37] xnox: hrm, a.conf -> initctl emit prepared / b.conf -> start on prepared # doesn't appear to be running the b job (at least I'm not catching any output from pre-start, post-start, or script .. end script [23:37] xnox: I am checking out the man pages and cookbook and it appears I'm doing right, but I suppose I'm not [23:37] styol: what do you mean catching any output? [23:38] styol: there is no output generated from "initctl emit" command. [23:38] xnox: pre-start exec echo "pre-start" >> /var/log/upstart.log # as an example [23:38] styol: it b job already running? [23:38] ah yeah that is fine, it seems though that the b job isn't reacting the emitted event from the a job [23:39] i don't believe so, i moved `start on [2345]` to A and instead put `start on prepared` in B [23:39] xnox: A has script /* stuff */ initctl emit prepared end script with carriage returns appropriately [23:41] styol: http://paste.ubuntu.com/7224070/ [23:41] styol: i've had "upstart-monitor" running in the background, hence the interractive feedback as to what happened. [23:41] ah that is pretty nice indeed, was wondering ;) [23:41] styol: if you have $ initctl log-level, you could adjust it to debug. [23:42] styol: and then in syslog / or somewhere else you should get more events printed. [23:42] seems it has log-priority but not seeing log-level [23:42] styol: if however b is already running, (like at the end of above) further "$ start a" will not trigger b job at all. [23:43] styol: yeah, crank up log-priority debug [23:43] yeah that makes sense indeed, shouldn't be as start on runlevel got replaced by start on prepared [23:43] ah ok [23:44] yeah hmm.. B isn't mentioned at all, lemme try a simplified version real quick [23:49] xnox: interesting, with your example it is causing the original B script to start, but in my real A script its `script /* more */ initctl emit prepared end script` [23:49] original = real [23:56] styol: note that upstart executes all scripts under "set -e" and "/bin/sh" (not bash, although it might be on your system) [23:56] styol: comment things out and start with minimal working sample and build up, until you spot mistake. [23:57] xnox: ah good thing to know indeed. Yeah seems it may have been a PEBCAK [23:57] for sure works right from the CLI, now to try a reboot