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