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