[09:59] <louischatriot> Hello
[17:20] <djszapi> slangasek ping
[17:21] <djszapi> I have installed 12.04 on my pandaboard, and that comes with this upstart version: 1.5-0ubuntu5. This version seems to support the logging out of the box in /var/log/upstart/myjob.log
[17:22] <slangasek> yep
[17:22] <djszapi> handy, I can use "tail -f /var/log/upstart/myjob.log"
[17:22] <slangasek> :)
[17:31] <djszapi> slangasek: my job is not run after a reboot, I do not understand
[17:32] <djszapi> upstart job: http://paste.kde.org/484466/
[17:32] <djszapi> lol it started VERY late.
[17:32] <djszapi> minutes after the boot
[17:33] <slangasek> with the 'stopped udevtrigger' start condition?
[17:34] <djszapi> I presume
[17:34] <djszapi> btw, does the upstart job have rights to write this folder ? /root/.config/MyStuff/foobar.conf ?
[17:34] <djszapi> the daemon works fine, if I run manually.
[17:34] <djszapi> but not if it is run via the upstart stuff
[17:35] <djszapi> the creation of that configuration does not happen in the latter case.
[17:38] <djszapi> if I execute exactly the same command as root, then the daemon works fine
[17:38] <djszapi> got a clue ?
[17:39] <djszapi> slangasek: ^
[17:39] <slangasek> an upstart job will run as root unless otherwise specified
[17:39] <djszapi> but why is it not working then without the upstart invocation ? :o
[17:40] <djszapi> it works fine manually...
[17:40] <slangasek> dunno
[17:40] <slangasek> seems like a case for strace
[17:40] <djszapi> I have not clue how to read the strace output
[17:40] <djszapi> I really see such a spammy output.
[17:41] <slangasek> I could interpret, but since you mention this is proprietary code, that may leak details of the inner workings that you might not wish to share
[17:41] <djszapi> exactly.
[17:41] <slangasek> the main thing would be to scan the strace output for references to that file
[17:41] <slangasek> and see what it's doing
[17:41] <djszapi> are you usre ?
[17:41] <djszapi> sure*
[17:43] <slangasek> I'm sure that's how I would debug it in your place :)
[17:45] <djszapi> exec strace ... ?
[17:45] <djszapi> in the upstart job ?
[17:47] <djszapi> slangasek: ^
[17:47] <slangasek> yes
[17:48] <slangasek> probably best to use 'exec strace -ff -o /var/log/debugging-my-app [...]'
[17:48] <slangasek> so that upstart doesn't itself have to process all the spammy output
[18:18] <djszapi> slangasek: damn
[18:18] <djszapi> I found the issue
[18:18] <djszapi> for some reason the stuff is not saved into ~/.config but into /.config (root fs, yes)
[18:19] <djszapi> if I run the daemon explicitely, the place for saving those is ~/.config
[18:19] <djszapi> slangasek: what does upstart do differently ?
[18:22] <slangasek> does your program rely on $HOME being set?
[18:22] <slangasek> because $HOME isn't set for upstart jobs
[18:23] <djszapi> slangasek: why the heck is that not set ??
[18:23] <slangasek> why *would* it be?
[18:24] <slangasek> you're not running the job in a login session
[18:24] <slangasek> it wouldn't be set for any init scripts started at boot time either
[18:25] <djszapi> well, /.config is super weird location
[18:25] <djszapi> it is the source of super maintenance waste of time
[18:25] <djszapi> config files are usually saved into a $HOME directory.
[18:26] <slangasek> not for system-level services, they aren't
[18:26] <djszapi> ofc, I run the job in a login session.
[18:26] <slangasek> and upstart jobs are system-level services
[18:26] <slangasek> you can always do 'env HOME=/root' as part of the job
[18:26] <djszapi> I know, but that is a hack.
[18:26] <slangasek> nope
[18:26] <slangasek> your assumption that $HOME should be set for you is incorrect
[18:27] <djszapi> no
[18:27] <djszapi> well
[18:27] <djszapi> let us ask differently.
[18:27] <djszapi> where are the system-level configs are stored ?
[18:27] <djszapi> you cannot automate that.
[18:27] <djszapi> perhaps directly in /etc/
[18:27] <djszapi> as in: /etc/MyCompany/myapp.conf
[18:27] <slangasek> system-level configs are stored in /etc, yes
[18:27] <slangasek> and normally, system-level programs don't need to be told that
[18:28] <slangasek> you appear to have a program which is normally run as a user and you're trying to run it as a system job
[18:32] <aaronlevy> I'm having trouble getting an upstart service to start on boot (ec2). I tried start on "network-services" as well as "memcached" but it doesn't seem to be even trying. Any suggestions on next steps to debug? I don't see anything in syslog for the service or anything 'init' related. 
[18:33] <aaronlevy> 1.5/precise fwiw
[18:35] <djszapi> slangasek: I am running a program which has stuff to store
[18:35] <djszapi> so I need to use a configuration file
[18:35] <djszapi> no matter which user runs that, it is run
[18:36] <slangasek> djszapi: fine, but that's a problem between your upstart job and the program itself
[18:36] <slangasek> upstart should not be setting $HOME
[18:37] <slangasek> aaronlevy: 'start on started memcached' may be what you're looking for
[18:38] <aaronlevy> slangasek: Sorry, typo. I do have "start on started <foo>"
[18:38] <slangasek> aaronlevy: is memcached an upstart job?
[18:38] <slangasek> if it's an init script, this won't work
[18:39] <aaronlevy> Yeah, it's init (or at least it doesn't have a .conf in /etc/init). Oddly that is the example they use in the cookbook
[18:39] <slangasek> really?
[18:39] <slangasek> so 'start on started memcached' will definitely fail; there are no upstart events generated for memcached in the current package
[18:40] <slangasek> because it's an init script and not an upstart job
[18:40] <slangasek> jodh: ^^ it might be a good idea to not use memcached as an example in the cookbook, for this reason?
[18:40] <aaronlevy> Yeah that might help :)… there are a handful of examples using it (task=, instances)
[18:41] <aaronlevy> Hmm. What is the recommended event to chain to (with networking available)?
[18:41] <slangasek> aaronlevy: what does the job you're trying to run actually do?  Does it have anything to do with memcached?
[18:42] <slangasek> 'start on runlevel [2345]' is the generic "my network and filesystem are available" rule
[18:42] <aaronlevy> slangasek: loosely. I was just using that as a separate test. I can do pre-start stuff to make sure what i need is running… just need it to at least try and start itself :)
[18:43] <aaronlevy> slangasek: fwiw, the cookbook also uses "network-services' as an abstract job example. But doesn't seem like that is an upstart job either. I guess I should have checked, but it does make things a little unclear
[18:44] <aaronlevy> Thanks for your help
[18:44] <slangasek> hmm, that's a rather unclear example, isn't it :/
[18:45] <slangasek> (1, 2) This job is not actually available in Ubuntu yet, but is expected to be added early in the 11.10 development cycle.
[18:45] <slangasek> oops
[18:53] <aaronlevy> Hmm. using [2345] still nothing. 
[18:54] <aaronlevy> wait. I messed up syntax. trying again
[18:59] <aaronlevy> Yup, working. Thanks again.
[19:39] <djszapi> slangasek: is there a way to run the daemon explicitely as root ?
[19:39] <djszapi> from the upstart job, that is.
[19:40] <djszapi> exec does not have a "-u" user switch
[19:40] <djszapi> su - ... or how ?
[19:40] <djszapi> that way, the HOME variable would be set
[19:42] <slangasek> no, it wouldn't
[19:42] <slangasek> if you want a HOME variable, set a HOME variable - I told you how :)
[19:43] <slangasek> well, running with su would set it maybe, but that's bad form
[19:43] <slangasek> because then you get a pam session as well, and you don't want that
[19:44] <slangasek> your application requires $HOME to be set, so just add 'env HOME=/root' and be done with it
[19:45] <slangasek> now, you *can* run upstart jobs as different users; there are 'setuid' and 'setgid' verbs.  But that has nothing to do with login shells and isn't going to set $HOME, and root is the default user
[19:49] <djszapi> slangasek: I do not understand why upstart tries to use a "user" (root as default) without setting the HOME user variable.
[19:49] <djszapi> that makes no sense.
[19:49] <djszapi> then do not use the "root" user.
[19:49] <slangasek> well, I'm sorry you don't understand, but this is how Unix *works*.
[19:49] <slangasek> this is nothing new to upstart.
[19:49] <djszapi> running stuff as a user has the consequency you *do* need to set the HOME variable.
[19:50] <slangasek> you would have gotten the exact same behavior with an init script.
[19:50] <djszapi> since the something that runs as a user would like to have a safe location for its stuff inside the home path...
[19:51] <djszapi> it is not all the apps' responsibility to set the stuff explicitely.
[19:54] <djszapi> slangasek: ^
[19:57] <slangasek> djszapi: no, it's not the app's responsibility, it's the upstart *job's* responsibility
[19:57] <slangasek> there's really no sense in arguing about this further; as I said, this is completely in line with how init scripts work, and it's not going to change
[19:58] <djszapi> this is really a bad design
[20:03] <slangasek> you're arguing with 30 years of history :)
[20:03] <djszapi> so did wayland...
[20:03] <djszapi> and won...
[20:07] <qkslvrwolf> hello, all.  I'm fairly new to working with upstart.  Working with VMs using Opennebula using LVM.
[20:08] <qkslvrwolf> I'm trying to get the contextualization to work.
[20:08] <qkslvrwolf> using upstart
[20:08] <qkslvrwolf> opennebula suggests updating /etc/init/networking.conf and /etc/init/network-interface.conf
[20:09] <qkslvrwolf> and having both of them run the static network IP address script in the pre-start scripts of both those files.
[20:10] <qkslvrwolf> I've done that, but I get "couldn't read /etc/network/interfaces" and "interface ethX declared allow-auto twice" in dmesg
[20:11] <slangasek> qkslvrwolf: umm.  are these opennebula suggestions available online somewhere?  I'd like to read exactly what they're suggesting and why
[20:11] <qkslvrwolf> yes
[20:11] <qkslvrwolf> one sec...
[20:12] <qkslvrwolf> http://dev.opennebula.org/projects/opennebula/repository/show/share/scripts
[20:13] <qkslvrwolf> http://dev.opennebula.org/projects/opennebula/repository/revisions/master/show/share/scripts/ubuntu/net-vmcontext
[20:13] <qkslvrwolf> the second one is the more direct link
[20:13] <qkslvrwolf> the README file has the suggestions I'm following.
[20:13] <slangasek> yuck
[20:14] <slangasek> fwiw, I strongly advise against editing the stock upstart jobs
[20:14] <qkslvrwolf> ok
[20:14] <qkslvrwolf> Fair.  
[20:14] <qkslvrwolf> Can you point me in the right direction for accomplishing a dynamic assignment of a static IP in a VM, then?
[20:15] <qkslvrwolf> ie., assign a static IP based on a dynamically generated mac address?
[20:15] <qkslvrwolf> at VM boot time?
[20:16] <slangasek> so you could do something like this, as a *separate* upstart job: http://paste.ubuntu.com/1001688/
[20:16] <slangasek> though honestly, I think this would make more sense as an upstart rule
[20:16] <slangasek> sorry
[20:16] <slangasek> udev rule
[20:30] <qkslvrwolf> Would you mine letting me know why you feel that way? 
[20:30] <qkslvrwolf> (learning purposes, not disagreement)
[20:31] <slangasek> because it's part of setting up the attributes on the device itself
[20:31] <slangasek> that's absolutely something that udev rules are for
[20:32] <qkslvrwolf> even though it's for the IP address?
[20:32] <qkslvrwolf> not the mac address?
[20:33] <slangasek> oh, I misunderstood the goal, sorry
[20:33] <qkslvrwolf> No, I'm sure I wasn't clear.
[20:33] <slangasek> in that case, yeah, it can be done as an upstart job
[20:34] <qkslvrwolf> ok
[20:36] <qkslvrwolf> And I'm guessing it makes most sense as a system job in /etc/init?
[20:36] <slangasek> if you're doing it as an upstart job, definitely
[20:37] <slangasek> btw, how does this upstream script know which interface it's being called for?
[20:38] <qkslvrwolf> the upstream script (if I used it unmodified) just does an ifconfig -a and takes steps for any interfaces it finds that aren't loopback.
[20:38] <qkslvrwolf> which is basically generating a stanza for /etc/network/interfaces
[20:38] <qkslvrwolf> based on the mac address it finds.
[20:39] <qkslvrwolf> which it did correctl...after boot I was able to ifup my interfaces and they came up fine
[20:39] <qkslvrwolf> during boot i got errors.
[20:39] <qkslvrwolf> but I didn't change anything
[20:39] <slangasek> ah, right
[20:40] <slangasek> so the problem is that it generates it once for /etc/init/networking.conf, and again for /etc/init/network-interface.conf, since *both* jobs are guaranteed to fire :)
[20:40] <qkslvrwolf> right.
[20:40] <qkslvrwolf> i wondered about that.
[20:40] <slangasek> and the upstream script doesn't clean up after itself
[20:40] <qkslvrwolf> So if I just chose one of them, it would probably work better?
[20:40] <slangasek> yeah
[20:40] <qkslvrwolf> is there one I should prefer?
[20:40] <slangasek> preferably /etc/init/network-interface.conf
[20:41] <qkslvrwolf> ok.  But won't that fire for each interface?
[20:42] <qkslvrwolf> the script handles them all at once...but then I guess networking starts on local-filesystems which probably doesn't guarantee the interfaces are up?
[20:46] <slangasek> correct, /etc/init/networking.conf isn't guaranteed to happen after all interfaces are up
[20:47] <slangasek> so if you have more than one interface... yeah, it'll still fire more than once :/
[20:47] <qkslvrwolf> Ok.  I actually just tested... I went ahead and kept it in networking.conf and removed form network-interface and it worked.  If it gives me problems I'll re-evaluage
[20:48]  * slangasek nods
[20:48] <qkslvrwolf> thank you so very much for your time...i appreciate the help.
[20:48] <slangasek> sure thing :)
[20:48] <djszapi> slangasek: anyway, I would personally change how qt works
[20:49] <djszapi> my dependency handling the configuration stuff, but the maintainer does not appreciate that :D
[20:49] <djszapi> so if both sides are stubborn, I need to work around both limitations :D
[20:50] <djszapi> of course everybody using a daemon with that framework has to do the same
[20:52] <slangasek> it's just a one-line fix-up in the upstart job ;)
[20:53] <djszapi> for /everybody/
[20:53] <djszapi> using a daemon with this framework at least
[20:53] <slangasek> well, yes
[20:53] <djszapi> perhaps even with others having the same design
[20:53] <slangasek> though I don't think qt is a particularly common framework for daemons
[20:53] <djszapi> it should be solved like I said
[20:54] <djszapi> no separate framework attentions should be made.
[20:54] <djszapi> or perhaps attention there would also be good for robustness
[20:54] <djszapi> why not ?
[20:54] <djszapi> qtcore is a total cool fit for daemons
[20:54] <slangasek> except for the bit where it cares about $HOME, which daemons should not ;)
[20:55] <slangasek> this is *not* a standard part of a daemon's environment
[20:55] <djszapi> like I said
[20:55] <djszapi> I proposed the change there as well
[20:55] <djszapi> if not set, do not use /.config
[20:55] <djszapi> but some sensible.
[20:55] <djszapi> but the bare minimum is a /big/ and /fat/ warning
[21:06] <djszapi> slangasek: thank you for your help anyway
[21:07] <slangasek> sure thing
[21:07] <djszapi> though env HOME=/root will not work
[21:07] <djszapi> slangasek: or is that an upstart specific syntax ? I thought that runs bash
[21:07] <djszapi> s/env/export/ might work
[21:08] <slangasek> that's an upstart-specific verb
[21:08] <slangasek> you set it outside your script
[21:08] <slangasek> so:
[21:08] <djszapi> I do not have script...
[21:08] <slangasek> env HOME=/root
[21:08] <slangasek> exec $foo
[21:08] <slangasek> the init(5) manpage explains this verb
[21:16] <djszapi> slangasek: right