| louischatriot | Hello | 09:59 |
|---|---|---|
| djszapi | slangasek ping | 17:20 |
| 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:21 |
| slangasek | yep | 17:22 |
| djszapi | handy, I can use "tail -f /var/log/upstart/myjob.log" | 17:22 |
| slangasek | :) | 17:22 |
| djszapi | slangasek: my job is not run after a reboot, I do not understand | 17:31 |
| djszapi | upstart job: http://paste.kde.org/484466/ | 17:32 |
| djszapi | lol it started VERY late. | 17:32 |
| djszapi | minutes after the boot | 17:32 |
| slangasek | with the 'stopped udevtrigger' start condition? | 17:33 |
| 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:34 |
| djszapi | the creation of that configuration does not happen in the latter case. | 17:35 |
| djszapi | if I execute exactly the same command as root, then the daemon works fine | 17:38 |
| djszapi | got a clue ? | 17:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| slangasek | I'm sure that's how I would debug it in your place :) | 17:43 |
| djszapi | exec strace ... ? | 17:45 |
| djszapi | in the upstart job ? | 17:45 |
| djszapi | slangasek: ^ | 17:47 |
| slangasek | yes | 17:47 |
| 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 | 17:48 |
| 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:18 |
| djszapi | if I run the daemon explicitely, the place for saving those is ~/.config | 18:19 |
| djszapi | slangasek: what does upstart do differently ? | 18:19 |
| slangasek | does your program rely on $HOME being set? | 18:22 |
| slangasek | because $HOME isn't set for upstart jobs | 18:22 |
| djszapi | slangasek: why the heck is that not set ?? | 18:23 |
| slangasek | why *would* it be? | 18:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:32 |
| aaronlevy | 1.5/precise fwiw | 18:33 |
| 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:35 |
| 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:36 |
| slangasek | aaronlevy: 'start on started memcached' may be what you're looking for | 18:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| aaronlevy | Thanks for your help | 18:44 |
| slangasek | hmm, that's a rather unclear example, isn't it :/ | 18:44 |
| 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:45 |
| aaronlevy | Hmm. using [2345] still nothing. | 18:53 |
| aaronlevy | wait. I messed up syntax. trying again | 18:54 |
| aaronlevy | Yup, working. Thanks again. | 18:59 |
| djszapi | slangasek: is there a way to run the daemon explicitely as root ? | 19:39 |
| djszapi | from the upstart job, that is. | 19:39 |
| 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:40 |
| slangasek | no, it wouldn't | 19:42 |
| slangasek | if you want a HOME variable, set a HOME variable - I told you how :) | 19:42 |
| 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:43 |
| slangasek | your application requires $HOME to be set, so just add 'env HOME=/root' and be done with it | 19:44 |
| 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:45 |
| 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:49 |
| 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:50 |
| djszapi | it is not all the apps' responsibility to set the stuff explicitely. | 19:51 |
| djszapi | slangasek: ^ | 19:54 |
| 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:57 |
| djszapi | this is really a bad design | 19:58 |
| slangasek | you're arguing with 30 years of history :) | 20:03 |
| djszapi | so did wayland... | 20:03 |
| djszapi | and won... | 20:03 |
| qkslvrwolf | hello, all. I'm fairly new to working with upstart. Working with VMs using Opennebula using LVM. | 20:07 |
| 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:08 |
| qkslvrwolf | and having both of them run the static network IP address script in the pre-start scripts of both those files. | 20:09 |
| qkslvrwolf | I've done that, but I get "couldn't read /etc/network/interfaces" and "interface ethX declared allow-auto twice" in dmesg | 20:10 |
| 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:11 |
| qkslvrwolf | http://dev.opennebula.org/projects/opennebula/repository/show/share/scripts | 20:12 |
| 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:13 |
| 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:14 |
| qkslvrwolf | ie., assign a static IP based on a dynamically generated mac address? | 20:15 |
| qkslvrwolf | at VM boot time? | 20:15 |
| 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:16 |
| qkslvrwolf | Would you mine letting me know why you feel that way? | 20:30 |
| qkslvrwolf | (learning purposes, not disagreement) | 20:30 |
| 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:31 |
| qkslvrwolf | even though it's for the IP address? | 20:32 |
| qkslvrwolf | not the mac address? | 20:32 |
| 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:33 |
| qkslvrwolf | ok | 20:34 |
| 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:36 |
| slangasek | btw, how does this upstream script know which interface it's being called for? | 20:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| qkslvrwolf | ok. But won't that fire for each interface? | 20:41 |
| 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:42 |
| slangasek | correct, /etc/init/networking.conf isn't guaranteed to happen after all interfaces are up | 20:46 |
| 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:47 |
| * 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:48 |
| 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:49 |
| djszapi | of course everybody using a daemon with that framework has to do the same | 20:50 |
| slangasek | it's just a one-line fix-up in the upstart job ;) | 20:52 |
| 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:53 |
| 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:54 |
| 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 | 20:55 |
| djszapi | slangasek: thank you for your help anyway | 21:06 |
| 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:07 |
| 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:08 |
| djszapi | slangasek: right | 21:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!