[00:01] dbus start/running, process 20286 [00:01] gnome-session start/running, process 20323 [00:01] nautilus start/running, process 20321 [00:01] compiz start/running, process 20322 [00:01] gnome-settings-daemon start/running, process 20320 [00:01] upstart-event-bridge start/running, process 20287 [00:01] that's a reasonable hybrid which gives me a working session, with the only problem that the session indicator doesn't show anything [00:13] alright, I have it in a packagable form, will push that to a PPA [00:28] slangasek: packaged and uploaded, will do a quick test on another machine and if it works as well as it does on mine, I'll send a mail to the team (for now) with a couple of notes on the problems I've spotted and had to workaround [00:28] (in short, our environment handling needs more work) [00:53] stgraber: sweet, nice going [10:49] gnome-session starts /etc/xdg/autostart/*.desktop (if conditions apply) last time I poked seb & pitti about it they didn't want to transition all of those to upstart jobs, cause then you'd want a bridge anyway to continue maintain support for those. [10:50] instead they wanted to transition _some_ of them to upstart jobs (the long running/idle/useful for events) [10:50] which I understand as the once that are shipped by default ;-) [16:41] I need some help writing an upstart script for some ruby processes [16:41] Right now the show up in ps as starting but then just disappear and respawn, all but one are non-forking so I'm not sure why it's so circular [17:20] marcoceppi: have you read http://upstart.ubuntu.com/cookbook/#expect (specifically http://upstart.ubuntu.com/cookbook/#how-to-establish-fork-count)? [17:23] jodh: I did, it forks 47 times :\ [17:23] Really not sure how to convey that to upstart [17:25] marcoceppi: it sounds rather broken. Is there any way you could arrange for a way for the main process to send SIGSTOP to itself? This is a facility to handle such unusual applications and indicates to Upstart that the process which sent itself SIGSTOP is the master (see init(5) for further details). [17:26] marcoceppi: presumably most of those forks are starting worker processes? If not, it's very broken. [17:27] jodh: I'm not sure, if it helps I'm trying to get sidekiq to run via upstart. So it's creating works [17:28] marcoceppi: sorry, never used it. You might find there is a way to run it in the foreground (and ideally stop it starting working processes until some later time). [17:29] jodh: when I run the process normally, it never detaches from console, none of them do [17:29] At least not by default. But when I remove the expect upstart doesn't exhibit the same results as when I run the command as my user [17:30] marcoceppi: ? In which case, it may well be failing to understand the environment upstart runs it in. See http://upstart.ubuntu.com/cookbook/#see-the-environment-a-job-runs-in and http://upstart.ubuntu.com/cookbook/#checking-how-a-service-might-react-when-run-as-a-job. [17:30] jodh: thanks for the links, I'll start there [17:31] marcoceppi: good luck! [18:51] Well, that doesn't really work well. [19:46] marcoceppi: perhaps the code is doing something clever like checking to see if stdin is a tty, and if it is, don't detach? [19:47] SpamapS: Probably, I'm not sure how to skirt around that. The application stores it's own "pid" file to they can track each other. Any way to tell upstart to use that files contents? [19:49] marcoceppi: yeah, if you just use the pre-start and post-stop [19:49] marcoceppi: you can't use respawn then [19:49] marcoceppi: and the pid won't be shown.. you're just using upstart to coordinate the job with other events at that point [19:50] marcoceppi: Its pretty silly if it can't just run in the foreground [19:50] SpamapS: I agree [19:51] As far as googling around I found foreman for ruby/rails that can create upstart scripts for your processes, which might be something I explore. Can't find any of the generated outputs from that though [19:56] marcoceppi: it should not be difficult... [19:57] marcoceppi: if it is.. the thing is overly complicated anyway [19:57] I would have hoped not [20:00] SpamapS: so how can I mimic a tty? I've tried playing with the console options but those don't seem to yield the results I wanted [20:05] If it helps, there are the three files I've created: https://gist.github.com/marcoceppi/4741567 [20:06] what are you trying to start? [20:08] Rails, sidekiq, and clockwork [20:09] From the command line, I use bundle which preloads a bunch of environment variables then executes the command based on options supplied [20:12] bundle is culprit here, but it's a pain to replicate what bundler does. [20:12] To me, this just seems like an extremely trivial thing, all the previous upstart scripts I've made for other software have been so straight forward. But this whole convoluded forking business, does it fork does it not what is it doing and I can't seem to figure out where to even start [20:12] bundler does ugly & crazy stuff despite looking innocent. [20:12] xnox: I figured, ugh this silly rails stuff has to be so complicated [20:14] marcoceppi: here http://serverfault.com/questions/327965/how-to-start-a-rake-task-using-upstart people complain about bundler [20:14] it works with rvm-shell (that one does less hacks) [20:15] I guess I'll have to install rvm-shell [20:16] there is also http://ddollar.github.com/foreman/ [20:17] I've seen people mention it. This isn't my project but I might see how hard it would be to put in upstream [20:40] SpamapS: xnox if it's any conselation. I got foreman to work, but foreman export upstart's scripts also fail [20:58] marcoceppi: doh [20:58] ruby: why you so bad