=== Guest47292 is now known as jrib
=== marcoceppi_ is now known as marcoceppi
robert_ancellI'm having trouble with session upstart in Ubuntu. I've forked gnome-settings-daemon into unity-settings-daemon and copied the upstart scripts (http://paste.ubuntu.com/6885290/, http://paste.ubuntu.com/6885292/). However, if I try and run a session gnome-session doesn't start. If I disable the gnome-settings-daemon script it does. So it appears the gnome-settings-daemon script is confusing the startup somehow13:56
robert_ancellAny ideas?13:56
robert_ancellhttp://paste.ubuntu.com/6885304/ is the output of upstart on a failed case13:57
robert_ancellIt doesn't mention gnome-settings-daemon at all13:57
jodhrobert_ancell: so unity-settings-daemon starts, but gnome-session does not. How are you disabling gnome-settings-daemon? Also, is there anything relevant in ~/.cache/upstart/*.log ?14:03
robert_ancelljodh, I'm disabling by moving the .conf to .conf.disabled14:04
robert_ancelljodh, I looked in the logs but couldn't see anything obvious14:04
robert_ancellI can bundle them up14:04
jodhrobert_ancell: unity7.conf specifies 'start on xsession SESSION=ubuntu and started gnome-settings-daemon' so if you've disabled gnome-settings-daemon that won't start (unless you've changed other .confs?)14:08
robert_ancelljodh, I have also changed that to do "or unity-settings-daemon"14:08
robert_ancellno other changes14:08
robert_ancellI notice there is a gnome-session log there, might be from a working boot though14:09
robert_ancellI'll clear the logs and retry14:09
jodhrobert_ancell: can you share the whole config for unity7 as that is likely the issue14:09
robert_ancellhttp://people.canonical.com/~bob/upstart-logs.tgz for the logs on a fresh run after clearing14:11
robert_ancellI mean14:11
jodhrobert_ancell: surely that won't work with gnome-settings-daemon though since gnome-settings-daemon specifies 'xsession SESSION!=ubuntu' but unity7 states 'xsession SESSION=ubuntu'14:11
robert_ancellwe are replacing gnome-settings-daemon with unity-settings-daemon in Unity14:12
robert_ancellgnome-settings-daemon should only run for GNOME etc14:12
jodhrobert_ancell: according to the logs, the unity7 job is stopping in pre-start and not starting compiz. Could that explain it?14:17
robert_ancelljodh, I think compiz is started by gnome-session currently14:17
robert_ancellso it's behaving correctly14:18
robert_ancellmy upstart logs in a normal session confirm that (compiz is in the gnome-session.log, unity7.log says "GNOME Session is starting Compiz")14:19
robert_ancellfancy coming into the office? ;)14:21
robert_ancelljodh, Is there any more information I can collect?14:26
xnoxrobert_ancell: jodh: the typical way to resolve this is to introduce an arbitrary sync event.14:27
xnoxrobert_ancell: jodh: e.g. both "unity-settings-daemon" and "gnome-settings-daemon" should do "initctl emit settings-daemon"14:27
Mariano9hi guys14:27
xnoxrobert_ancell: then unity7 would start on "xsession SESSION=ubuntu and settings-daemon"14:27
robert_ancellok, I can try that14:28
xnoxrobert_ancell: ditto e.g. gnome/other desktop environments can do something else.14:28
Mariano9is there a command to check if an upstart job is correctly formated? like init-chkconfig or some?14:28
xnoxrobert_ancell: that way one would also be free to use one of the alternative settings-daemons.14:28
jodhMariano9: yes - I put it in the mail I sent you - init-checkconf /path/to/job.conf14:29
xnoxrobert_ancell: one would do "initctl emit settings-daemon" in e.g. post-start14:29
Mariano9hey jodh14:29
Mariano9cannot find the command14:29
Mariano9it isn't there, init-chkconfig14:29
xnoxrobert_ancell: this is similar to how "indicators-*" start events work, it's simply emitted when indicators should start loading. And e.g. unity, gtk3-old-style-applet and others emit it to indicate they are ready to receive indicators.14:29
jodhMariano9: it's *init-checkconf* not chkconfig14:30
Mariano9sorry, init-chkconf14:30
Mariano9"init-checkconf /etc/init/newrelic_rs_dfw_1.conf, -bash: init-checkconf: command not found"14:31
xnoxMariano9: what version of upstart are you using?14:31
jodhMariano9: run "initctl version" to establish that14:32
xnoxMariano9: excellent =) so pre-historic. Well, we can attempt to valide that job for you by reading it, if you can pass it on to us. e.g. paste.ubuntu.com14:33
Mariano9haha, just a sec14:34
robert_ancellxnox, same problem after adding the settings-daemon event. Still works if disabling the gnome-settings-daemon config14:36
Mariano9xnox: there you go14:37
Mariano9(notice that I've commented some lines as I'm trying to get it goint)14:37
jodhMariano9: you have 2 execs - only the last will be honoured.14:37
xnoxrobert_ancell: hm. Is there a ppa i can try, or is just by co-installing gnome & ubuntu settings daemon on my desktop?14:37
seb128xnox, you should come to the office to help us debug those g-s-d u-s-d issues ;-)14:38
xnoxseb128: you want me to comute into the office _now_ ?! =)14:38
seb128xnox, tomorrow morning would work as well ;-)14:38
seb128strike should be over then?14:38
robert_ancellxnox, it's not in a PPA at the moment, but I could add it14:38
jodhMariano9: assuming you are running ubuntu lucid, procenv won't be available unless you built it from source?14:39
Mariano9nope, centOS 6.x here14:39
xnoxseb128: i use trains anyway, so i'm unaffected. Tube is mostly non-existent south of the river.14:39
jodhMariano9: what output do you get if you run "sudo start newrelic"?14:39
jodhMariano9: ah, ok :)14:39
robert_ancellxnox, if you could come in tomorrow that would be great, we don't need to solve this immediately14:40
Mariano9"newrelic_rs_dfw_1 start/running, process 9251"14:40
Mariano9upstart sees it as running normal, but it isn't14:40
xnoxMariano9: that gist has two exec lines, i think last one wins.14:40
xnoxMariano9: the problem is the "bundle exec" was that that strange thing for ruby?14:40
Mariano9xnox: yes, it's a ruby gem14:41
xnoxMariano9: that will not work nicely as bundle forks many times and relies on environment variables and HOME, neither of which are set from within upstart14:41
xnoxMariano9: so you need probably need to do:14:41
jodhMariano9: comment out the last line (exec bundle) so that upstart runs procenv first if you have that installed, then diff /tmp/procenv-job.log with a procenv log you take in an environment it does start in.14:41
xnox    source /path/to/bundle.sh14:41
jodhMariano9: as mentioned, it may well be env vars. I have no idea what newrelic is but does it need $HOME?14:42
xnox    bundle exec /path/to/newrelic_rs14:42
xnoxend script14:42
xnoxMariano9: and you probably want "expect daemon"14:42
xnoxMariano9: how is your bundle installed? user level or system-wide/root ?14:42
Mariano9xnox: jodh ok, does it matter the order of the stanzas?14:43
xnoxMariano9: you can't have duplicates, and at the moment I see two "exec" stanzas.14:43
jodhMariano9: no, but as mentioned, if you specify a particular stanza multiple times, only the last is honoured.14:43
xnoxMariano9: it's declarative, not a top-down execution.14:43
jodhxnox: we've already covered that - see above14:43
xnoxah, sorry =)14:43
Mariano9right, i meant different stanzas order14:43
Mariano9but, it's declarative, so it doesn't matter the order14:44
xnoxMariano9: order of different stanzas does not matter, so you can have "start on" at the very end, etc.14:44
Mariano9great, let's try those14:44
xnoxMariano9: you should source bundle environment, it usually drops a script in /etc/profile.d or the users ~/.bashrc and the like. Not sure where it would live on a CentOS system however.14:46
xnoxMariano9: without that, bundle is mostly non-operational.14:46
xnoxrobert_ancell: ok, i'll be in tomorrow.14:46
xnoxrobert_ancell: and we can debug it.14:46
robert_ancellxnox, thanks14:46
seb128xnox, thanks14:46
Mariano9xnox: i think it's the same folder as newrelic_rs14:50
xnoxMariano9: right, so try:14:51
xnox    source that-file14:51
xnox    bundle exec14:51
xnoxend script14:51
Mariano9because if I cd into it and run bundle exec ./bin/newrelic_rs, it will start great14:51
xnoxMariano9: due to chdir stanza you should be in the right directory already.14:51
xnoxMariano9: right, but bundle probably installed a script somewhere for your shell to find and source whenever you enter that directory.14:52
Mariano9like a link?14:52
xnoxMariano9: so one needs that "magic" snippet in the same way.14:52
xnoxMariano9: it's been many years since I last used bundle =)14:52
Mariano9source stanza will give the right path to execute the bundle command right?14:55
xnoxsource is not a stanza, source is a sh built in command14:55
xnoxthings between script... end script are just normal shell lines executed.14:56
xnoxand that would be replacing exec.14:56
Mariano9so, again, bundle path is the same as newrelic_rs then14:56
xnoxMariano9: oh there appears to be an easy solution for bundler.14:56
xnoxMariano9: --deployement --binstubs options14:57
xnoxMariano9: http://askubuntu.com/questions/105761/how-to-get-a-bundler-enabled-rails-app-running-as-a-service-with-upstart14:57
xnoxMariano9: apart from changing start on/stop on to what you had, it should just work on centos.14:58
Mariano9let's see14:58
Mariano9two questions xnox: 1- what if the stop job hangs?15:01
Mariano9how do I actually stop the initctl job?15:02
Mariano9"init: Sending TERM signal to newrelic_rs_dfw_1 main process (11127)" and will stay there for ever15:02
Mariano9ctrl+c, now it is shown as stop/killed, process 1112715:04
xnoxMariano9: after starting a job establish if the reality matches upstart expectations.15:05
xnoxMariano9: which is: process id in `ps' output matches, initctl status.15:06
xnoxMariano9: if they don't, the expect stanzas are wrong. more recent upstart handles such situations better.15:06
xnoxMariano9: but in your case you probably will need to add "expect fork", or "expect daemon".15:06
xnoxMariano9: and to clear the state, you'd need to re-exec upstart -> which actually for such old upstart means reboot.15:07
xnoxMariano9: i hope you are not developing this job on a production server.15:07
Mariano9host reboot?15:08
Mariano9there's no process in ps from newrelic, I've added the expect daemon before executing the start15:10
Mariano9is there a way to upgrade this version?15:10
Mariano9in fact there is15:12
Mariano9would it be good to upgrade it?15:12
xnoxMariano9: i don't know. I wonder if we should explore pushing a more up to date upstart into EPEL repositories.15:42
Mariano9xnox: so in order to clear the state I need to reboot the server?15:56
xnoxMariano9: or rename the job ;-) then the state is clear for the "new job name".15:59
Mariano9xnox: right, eventually I'll have tons of jobs :) 16:01
Mariano9xnox: is there a way to reload configuration once a job script is edited?16:02
xnoxMariano9: the configuration is automatically reloaded, but it will only take affect on newly start instance. So e.g. after a proper $ stop foo, the next $ start foo will use new configuration.16:04
xnoxMariano9: reload/restart is not enough, those keep on using the in-memory configuration.16:04
mc_bluebeardIs it advisable to have an exec command that "blocks"…ie, that does not daemonize or return, but is instead long-running?19:39
JanCif you can, sure20:05
xnoxmc_bluebeard: you can do that, in that case "your command is ~ running in foreground" and then you shouldn't specify any "expect ..." stanza.23:04

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!