[11:49] <muzzol> hi
[11:50] <muzzol> is there any variable that holds the action that triggers it? (start, stop, restart)
[11:51] <muzzol> i want to do something like this: http://pastebin.com/XFJJsceu
[11:51] <muzzol> is that possible?
[16:49] <lpapp> jodh: hey, I do not understand what upstart does, but when I run the command manually, the "daemon" works as expected unlike with an upstart job :(
[16:50] <jodh> lpapp: where does $ACTION come from?
[16:51] <jodh> lpapp: have you looked at http://upstart.ubuntu.com/cookbook/ ?
[16:52] <jodh> lpapp: your job looks good aside from that variable which isn't being set, so the script will presumably fail. See also http://upstart.ubuntu.com/cookbook/#obtaining-a-log-of-a-script-section
[16:56] <djszapi> jodh: do you have a clue what can cause that ?
[16:57] <djszapi> http://paste.kde.org/483674/ -> this is my upstart job
[17:12] <doki_pen> what's the best way to kick off a proc as an unprivileged user?
[17:23] <djszapi> init-checkconf /etc/init/foobar.conf
[17:23] <djszapi> ERROR: failed to ask Upstart to check conf file
[17:23] <djszapi> what is this, SpamapS ideas ?
[17:25] <djszapi> slangasek: same issue again
[17:26] <djszapi> the exec line works, if I run manually.
[17:26] <djszapi> but if I use start foobar, it does not.
[17:26] <slangasek> oh, really?
[17:26] <slangasek> so even running 'start foobar' fails?
[17:27] <djszapi> nope
[17:27] <djszapi> funky thing is that, the ps aux
[17:27] <djszapi> output shows the process execed :D
[17:27] <djszapi> but the daemon does not work as expected.
[17:27] <slangasek> djszapi: is the code for the daemon open?
[17:28] <slangasek> also, can you try modifying the job to run /usr/bin/foobar under strace, and capture the syscall output?
[17:28] <djszapi> slangasek: first step would be to get the daemon output logged into somewhere.
[17:29] <djszapi> no, the daemon is a commercial stuff
[17:29] <djszapi> cannot disclose, sorry.
[17:29] <slangasek> ok
[17:29] <djszapi> but that helps, if I know how to log the output.
[17:29] <slangasek> daemon output logged> what version of Ubuntu are you running again?
[17:29] <slangasek> the upstart from 12.04 has logging support
[17:30] <djszapi> Linux linaro-ubuntu-desktop 3.1.1-26-linaro-lt-omap #26~lt~ci~20120325001352+1332635991~4f6ec49b-Ubuntu SMP PREEMPT  armv7l armv7l armv7l GNU/Linux
[17:31] <djszapi> 1.3-0ubuntu12~linaro2
[17:31] <slangasek> if you're using 12.04, or if you can upgrade upstart to that version, you'll get a /var/log/upstart/foobar.log containing all the output
[17:31] <slangasek> otherwise, you can use shell redirection directly in the upstart job
[17:31] <slangasek> exec /usr/bin/foobar receive /dev/ttyUSB0 38400 > /var/log/my-log 2>&1
[17:31] <slangasek> ^^ should work
[17:32] <slangasek> if it *doesn't* work, you just need to wrap the exec with a script / end script
[17:33] <djszapi> let us see if that redirection works.
[17:59] <djszapi> slangasek: foudn the issue. The log helped a lot, thanks.
[17:59] <djszapi> it is now working :)
[17:59] <slangasek> ok
[21:56] <gchristensen> hi, my upstart script seems to fail to start when the system is starting, even though I've given it a very relaxed respawn limit, and even put a 3 second sleep in the script. here it is: https://gist.github.com/96512f0ef329d5b022e4
[22:00] <slangasek> gchristensen: a) your start and stop conditions are identical, which is certainly an error; b) 'mysql' is not a standard upstart event, so unless you've written something that outputs it, you'll never satisfy the start condition
[22:00] <gchristensen> I see
[22:00] <slangasek> you probably want 'start on started mysql'
[22:00] <slangasek> and 'stop on stopping mysql'
[22:01] <JoeJulian> If an upstart script has to wait for the network to be started, what's the string it needs to WAIT_FOR?
[22:02] <gchristensen> slangasek: that might do it. thank you for your help, I'll read the manual closer
[22:02] <slangasek> your 'sleep 3' should be unnecessary, btw; the mysql upstart job should, like all upstart jobs, have already been written such that the mysql server is up and ready to receive queries before emitting 'started'
[22:02] <gchristensen> slangasek: that was a last-ditch attempt
[22:03] <slangasek> JoeJulian: unless there's a specific reason that your service needs to start earlier, best practice here is 'start on runlevel [2345]'
[22:04] <JoeJulian> So the network should be started already at that point?
[22:04] <slangasek> JoeJulian: definitely
[22:05] <JoeJulian> The problem seems to be with semiosis' upstart scripts for glusterfs. One user has encountered an issue with resolving hostnames while glusterd is starting. I presumed this was due to the network not being started.
[22:05] <slangasek> JoeJulian: the exception is if your network is controlled by network-manager, in which case there's no guaranteed synchronization event for the network being up
[22:05] <JoeJulian> Does debian use network-manager? (not a debian user myself)
[22:06] <slangasek> JoeJulian: Debian supports network-manager... it would not be used by default on a server, be it Debian or Ubuntu
[22:07] <slangasek> and Debian also doesn't use upstart
[22:07] <slangasek> (currently)
[22:08] <JoeJulian> Ok. Thank you. I'm not very good at supporting non-rpm based distros. :D
[22:09] <slangasek> :)
[22:09] <slangasek> so are the upstart jobs that you're concerned about different than the ones in the glusterfs-server package shipped in Ubuntu?
[22:10] <slangasek> (which does indeed show 'start on runlevel [...]'
[22:10] <slangasek> )
[22:10] <JoeJulian> I /think/ that those are, indeed, the ones that semiosis wrote.
[22:11] <JoeJulian> And I got two users mixed up. It is ubuntu.
[22:12] <slangasek> right - that's much more plausible :)
[22:12] <slangasek> so yeah, if it was a server install, the existing job should already be correct
[22:12] <slangasek> if someone's doing this on a desktop install, there could be problems, depending on the configuration of network-manager
[22:12] <JoeJulian> This guy is a former windows admin. I think you're on to something with the networkmanager idea. 
[22:13] <gchristensen> slangasek: what "start on" output should I be listening to for something that expects networking and a writable filesystem? ie: a generally usable machine
[22:13] <slangasek> gchristensen: that's precisely the 'start on runlevel [2345]' I mentioned to JoeJulian 
[22:13] <JoeJulian> Looks like you need a bot with an automatic notice. :D
[22:13] <JoeJulian> hehe
[22:14] <slangasek> if you look in /etc/init/rc-sysinit.conf, you'll see this defined in terms of 'filesystem and static-network-up'
[22:14] <gchristensen> I see
[22:15] <gchristensen> thank you
[22:24] <JoeJulian> "Desktop 32bit. Stock image"! Thanks slangasek. Good catch.
[22:24] <slangasek> ok
[22:25] <slangasek> too bad that there's no upstart event to key on in that case
[22:25] <slangasek> but yeah, if the user can switch to static network config via /etc/network/interfaces, it'll work around this problem
[22:26] <JoeJulian> It's supposed to be a server anyway. I'll just make him reinstall.
[22:27] <slangasek> :)