[00:03] <axisys> I am on upstart 0.6.5 .. so I guess just comment out start on line would be my only choice?
[00:03] <axisys> i am on lucid lts
[15:56] <SpamapS> axisys: yes thats the option you have on lucid
[16:20] <axisys> SpamapS: thanks
[16:54] <pmjdebru1jn> hi again
[16:55] <pmjdebru1jn> I'm using/contributing to UCK (Ubuntu Construction Kit)
[16:55] <pmjdebru1jn> which allows one to remaster Live CD ISOs by rebuilding the squashfs
[16:55] <pmjdebru1jn> most of it works fine
[16:55] <pmjdebru1jn> as far as I can tell it surpresses the starting of services mv /bin/initctl /bin/initctl.blocked; ln -s /bin/true /bin/initctl
[16:56] <pmjdebru1jn> however when the upstart packages gets upgraded that link is replaced with an original binary again, and services can be started again
[16:56] <pmjdebru1jn> there here a more robust way to inhibit upstart from starting services?
[16:56] <pmjdebru1jn> like policy-rc.d ?
[17:17] <JanC> pmjdebru1jn: about your question about an upstart config file yesterday: I don't think there is one
[17:18] <JanC> but on a "normal" Ubuntu system with GRUB you can add it to /etc/default/grub
[17:20] <JanC> I'm not 100% that works without an initrd though
[17:21] <JanC> well, I guess it could work (I suppose it works as long as update-grub is run on kernel upgrades?)
[17:24] <JanC> and if you want to inhibit certain services from starting, just add a servicename.override which doesn't have a "start on" line in /etc/init/
[17:27] <JanC> starting nothing sounds like a very weird thing to me  ☺
[17:27] <pmjdebru1jn> JanC: I already used --no-log passed via pxelinux
[17:28] <pmjdebru1jn> JanC: well, chroot environments
[17:28] <pmjdebru1jn> it's fairly common
[17:29] <pmjdebru1jn> the problem with the .override file is that I can't predict which services need blocking
[17:29] <pmjdebru1jn> the debian policy-rc.d allows everything to be blocked
[17:29] <pmjdebru1jn> which is ideal for this use-case
[17:29] <pmjdebru1jn> the lame solution would be to just hold upstart, and to never upgrade it when remastering the cd
[17:29] <pmjdebru1jn> but that would be a shame
[17:29] <JanC> do you actually need upstart to be installed then?
[17:30] <pmjdebru1jn> "installed"?
[17:30] <pmjdebru1jn> upgraded
[17:30] <pmjdebru1jn> upstart is already on the live cd
[17:30] <JanC> if it isn't installed, you never upgrade it...
[17:30] <pmjdebru1jn> huh?
[17:30] <JanC> and you can remove it, of course
[17:30] <pmjdebru1jn> it's the desktop cd
[17:30] <pmjdebru1jn> removing upstart will criple it
[17:30] <JanC> well, I'm not sure what you try to do
[17:31] <pmjdebru1jn> as in ubuntu-12.04-desktop-amd64.iso  
[17:31] <pmjdebru1jn> modifying the ubuntu live cd
[17:31] <pmjdebru1jn> uck, unpack the squashfs, chroot's to it, allows you to modify stuff, and then repacks it
[17:31] <pmjdebru1jn> nifty stuff
[17:32] <JanC> ah, so you need to disable upstart while doing the changes in the chroot?
[17:32] <JanC> scripted chengexs
[17:32] <JanC> changes
[17:32] <pmjdebru1jn> right
[17:32] <pmjdebru1jn> but the disabling of upstart needs to be able to survive upstart package upgrades
[17:33] <pmjdebru1jn> uck alreayd disables starting of services by diverting /sbin/initctl
[17:33] <pmjdebru1jn> but that fails when upstart is upgraded
[17:33] <JanC> because changes might include upgrades...
[17:33] <pmjdebru1jn> including updates into the ISO is a huge boon
[17:33] <pmjdebru1jn> especially a few month's after release
[17:35] <JanC> hm, does initctl actually look at the upstart config files in the chroot?
[17:36] <JanC> I would assume upstart is running outside it
[17:36] <pmjdebru1jn> sure
[17:37] <pmjdebru1jn> but divering initclt means dpkg just executes /bin/true instead of calling upstart
[17:37] <pmjdebru1jn> thus the service doesn't get started, without any further errors
[17:37] <pmjdebru1jn> until the upstart package itself is upgraded
[17:38] <pmjdebru1jn> it's possibly to deal with this situation manually
[17:38] <JanC> I'm starting to understand the problem, I think...
[17:38] <pmjdebru1jn> but I'm looking for a structural solution, so people using uck aren't hit by this issue
[17:38] <pmjdebru1jn> there are also upgrade problems with grub
[17:38] <pmjdebru1jn> but I just added some code, to hold those packages, so they aren't upgraded accidentally
[17:39] <pmjdebru1jn> so if nothing else works, I guess I could do that too for upstart,
[17:39] <JanC> I wonder if a fake upstart dbus service inside the chroot is possible...   ;)
[17:39] <pmjdebru1jn> heh
[17:39] <pmjdebru1jn> that's nasty
[17:39] <JanC> just fake you are upstart (inside the Chroot)
[17:39] <JanC> and do nothing
[17:39] <pmjdebru1jn> yeah
[17:40] <pmjdebru1jn> I was hoping upstart had a standard feature for this
[17:40] <pmjdebru1jn> as it's not that uncommon
[17:40] <pmjdebru1jn> I wonder how they do this when generating the live cd's from scratch
[17:40] <pmjdebru1jn> similar issues must occur
[17:40]  * pmjdebru1jn wonders if systemd also discounts lots of use-cases like upstart :(
[17:41] <pmjdebru1jn> I used to like to idea of replacing SysV init... not so much anymore
[17:42] <pmjdebru1jn> https://help.ubuntu.com/community/LiveCDCustomizationFromScratch/
[17:42] <pmjdebru1jn> dpkg-divert --local --rename --add /sbin/initctl
[17:42] <pmjdebru1jn> at least there they use a dpkg-divert
[17:42] <pmjdebru1jn> instead of just mv / ln
[17:43] <JanC> that's more likely to persist indeed
[17:43] <pmjdebru1jn> right
[17:44] <pmjdebru1jn> but then I wonder where to initctl binary in the newer packages is placed
[17:45] <pmjdebru1jn> https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/430224
[17:45] <pmjdebru1jn> it's marked won't fix
[17:46]  * pmjdebru1jn sighs
[17:46] <pmjdebru1jn> oh wait
[17:46] <pmjdebru1jn> got re-opened
[17:49] <pmjdebru1jn> Chroot support is now available in Upstart 1.3.
[17:49] <pmjdebru1jn> hmmm
[17:50] <pmjdebru1jn> https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverviewUpstart
[17:51] <pmjdebru1jn> ok
[17:51] <pmjdebru1jn> so this behavior was actually _added_ to support vserver/lxc etc
[17:51] <pmjdebru1jn> and can be disabled system-wide
[17:51] <pmjdebru1jn> which means fiddling with kernel options
[17:51] <pmjdebru1jn> :(
[17:58] <pmjdebru1jn> anyhow
[17:58] <SpamapS> pmjdebru1jn: AFAIK, the upstart chroot support has nothing to do with vserver/lxc
[17:58] <SpamapS> pmjdebru1jn: since neither of those use pure "chroots"
[17:58] <pmjdebru1jn> ok
[17:58] <pmjdebru1jn> then I'm not sure why that's built into upstart
[17:59] <SpamapS> they both namespace the kernel
[17:59] <SpamapS> pmjdebru1jn: for actual chroots
[17:59] <pmjdebru1jn> as without vserver/lxc you usually don't want stuff to actually RUN in a chroot
[17:59] <SpamapS> pmjdebru1jn: it comes in handy for testing
[17:59] <pmjdebru1jn> heh
[18:00] <pmjdebru1jn> possibly
[18:00] <pmjdebru1jn> it's a PITA as it seems it can't be disabled _easily_
[18:00] <pmjdebru1jn> but dpkg-divert will probably work well enough
[18:12] <jMCg> Hello happy people o/~
[18:12] <jMCg> I have upstart 1.5 running and a job which is in the state of: logstash stop/killed, process 18506
[18:13] <jMCg> The job itself was killed, I was so clever as to pkill it, so that upstart would restart it, and I would have it reload the config.
[18:13] <jMCg> My being clever wasn't all that clever at all. Now I'm stuck in this state.
[18:18] <jMCg> .
[18:20] <JanC> starting the job doesn't work?
[18:23] <jMCg> JanC: nope, hangs the same as stop logstash
[18:24] <jMCg> http://dpaste.com/767785/
[18:24] <jMCg> Of course this tracks the 'su', but even so, it should've respawned the friggin job, because it's *all* gone.
[18:27] <JanC> hm, I seem to remember start-stop-daemon is currently the officially recommended way instead of su
[18:27] <jMCg> oh crap. There's setuid/setgid now?!
[18:27] <jMCg> In 1.5, that is..
[18:27] <JanC> that too
[18:29] <jMCg> So, on Ubuntu 10.04 I should use start-stop-daemon, and on 12.04 I should use setuid/setgid then.
[18:29] <JanC> you can use s-s-d on both, I suppose
[18:31] <jMCg> Yeah, but I'd rather not :P
[18:32] <jMCg> Well, that still doesn't quite help me with the start/stop that doesn't start/stop :-/
[18:42] <jMCg> /proc/self/fd/9: 2: /proc/self/fd/9: setuid: not found
[18:53] <SpamapS> jMCg: if you have a process listed that isn't running, you set 'expect fork' incorrectly
[18:54] <jMCg> SpamapS: yeah, and how do I fix it, other than rebooting the machine?
[18:55] <SpamapS> jMCg: loop fork/wait until the process comes up, then wait for upstart to see it and let go
[18:55] <SpamapS> jMCg: there's a ruby and a python version of that out there
[18:55] <jMCg> O_o
[18:55] <SpamapS> I'm surprised we haven't fixed that with an 'initctl forget-pid job-name'
[18:55] <SpamapS> jodh: ^^
[18:56] <jMCg> There's a forget-pid?!
[18:56] <jMCg> Oh. No there isn't.
[18:56] <SpamapS> http://paste.ubuntu.com/1076921/
[18:56] <SpamapS> jMCg: there *SHOULD* be a forget-pid
[18:56] <SpamapS> or even better, we should stop abusing ptrace. :)
[18:57] <jMCg> SpamapS: yes
[18:57] <jMCg> Oh how I yearn for Solaris' simplicity..
[18:57] <jMCg> Did I just seriously say Solaris' simplicity?!
[18:57] <SpamapS> hahahahhaaha
[18:57] <SpamapS> jMCg: I tend to recommend that people just avoid 'expect fork' or 'expect daemon'
[18:57] <jMCg> Anyway, solaris has a process-contract by default, so you follow that and don't care about the forks or how many there are.
[18:58] <jMCg> SpamapS: *nod*
[18:58] <SpamapS> use a post-start to determine when the job is ready
[18:58] <SpamapS> since fork() is actually also rarely the time when things are ready.. just closer to it than exec()
[18:58] <jMCg> So, first: Does that thing work with python != 3?
[18:59] <SpamapS> jMCg: probably
[18:59] <SpamapS> jMCg: I wrote it as python3 as part of my "getting used to python 3" experiment :)
[19:02] <jMCg> SpamapS: how often/long will it have to run?
[19:04] <SpamapS> jMCg: just run it once.
[19:04] <SpamapS> jMCg: it will loop through the whole pid space until it finds the necessary pid
[19:04] <jMCg> SpamapS: okay. That fixed it. Now on to the next issue:
[19:05] <jMCg> /proc/self/fd/9: 3: /proc/self/fd/9: setuid: not found
[19:05] <SpamapS> jMCg: thats weird
[19:05] <jMCg> When I set setuid logstash/setguid adm
[19:05] <jMCg> http://dpaste.com/767807/
[19:05] <jMCg> That's the whole deal.
[19:07] <SpamapS> ahh wrong place
[19:08] <SpamapS> jMCg: they're root stanzas, not in the shell
[19:08] <SpamapS>         exec java -jar logstash.jar agent -f logstash.conf --log logstash-indexer.out -- web --log logstash-web.out --backend elasticsearch://localhost/
[19:08] <SpamapS>         emit logstash-indexer_running
[19:08] <SpamapS> jMCg: also on that, exec never returns
[19:08] <SpamapS> so emit will never happen
[19:08] <SpamapS> and I don't believe it is a sub-command in the path, so 'initctl emit'
[19:08] <SpamapS> jMCg: further, you don't need that emit.. 'started logstash' is the same event
[19:09] <jMCg> SpamapS: yeah, but that's not so much the issue as the setuid stuff ;)
[19:10] <jMCg> ah
[19:10] <jMCg> root stanzas, now I see
[19:10] <jMCg> SpamapS: but the chdir is not?
[19:11] <SpamapS> jMCg: chdir is also a root stanza
[19:11] <SpamapS> jMCg: tho it also exists in shell, which is why thats working.
[19:11] <SpamapS> jMCg: I'd put it at the root tho, much cleaner
[19:11] <SpamapS> 	[ -f ./logstash.rc ] && . ./logstash.rc 
[19:11] <SpamapS> jMCg: you can also elimiate that and just use env statements at the root
[19:12] <SpamapS> unless there's some important reason that it might be there instead
[19:19] <jMCg> SpamapS: nope. There is not.
[19:35] <thinkingpotato> is it possible some services cannot be controlled using Upstart? I have a case I can't get working, checked everything I possibly could (based on cookbook, forums, blogs, stackoverflow etc.)
[19:48] <jMCg> SpamapS: but env cannot be a file.
[19:54] <SpamapS> jMCg: right, thats the point, so if you need it in a file, leave it as-is.. but if you can store it all in one .conf file with env X=y statements, do that.
[19:54] <SpamapS> thinkingpotato: no, upstart can "control" any service. What is possible is that the pid of the daemon may have to be tracked using pidfiles rather than upstart's methods (making respawn challenging)
[19:58] <thinkingpotato> SpamapS: thanks for the answer, so approach such as http://askubuntu.com/a/4413 could give me some results?
[20:21] <jMCg> SpamapS: where's the init(5)'s source?
[20:21] <jMCg> found.
[20:26] <thinkingpotato> ok, I tried setting manual start - apparently it depends on some other services, because I'm able to start it from console, good thinking?
[21:03] <pmjdebru1jn> JanC: btw just tested, dpkg-divert practically solved my problem
[21:56] <thinkingpotato> 10 hours later: that was a wrong uid/gid I started with... problem solved, works like charm