| 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 | 00:03 |
| SpamapS | axisys: yes thats the option you have on lucid | 15:56 |
| axisys | SpamapS: thanks | 16:20 |
| pmjdebru1jn | hi again | 16:54 |
| 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:55 |
| 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 ? | 16:56 |
| JanC | pmjdebru1jn: about your question about an upstart config file yesterday: I don't think there is one | 17:17 |
| JanC | but on a "normal" Ubuntu system with GRUB you can add it to /etc/default/grub | 17:18 |
| JanC | I'm not 100% that works without an initrd though | 17:20 |
| JanC | well, I guess it could work (I suppose it works as long as update-grub is run on kernel upgrades?) | 17:21 |
| 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:24 |
| JanC | starting nothing sounds like a very weird thing to me ☺ | 17:27 |
| pmjdebru1jn | JanC: I already used --no-log passed via pxelinux | 17:27 |
| pmjdebru1jn | JanC: well, chroot environments | 17:28 |
| pmjdebru1jn | it's fairly common | 17:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| JanC | hm, does initctl actually look at the upstart config files in the chroot? | 17:35 |
| JanC | I would assume upstart is running outside it | 17:36 |
| pmjdebru1jn | sure | 17:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 | |
| pmjdebru1jn | I used to like to idea of replacing SysV init... not so much anymore | 17:41 |
| 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:42 |
| JanC | that's more likely to persist indeed | 17:43 |
| pmjdebru1jn | right | 17:43 |
| pmjdebru1jn | but then I wonder where to initctl binary in the newer packages is placed | 17:44 |
| pmjdebru1jn | https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/430224 | 17:45 |
| pmjdebru1jn | it's marked won't fix | 17:45 |
| * pmjdebru1jn sighs | 17:46 | |
| pmjdebru1jn | oh wait | 17:46 |
| pmjdebru1jn | got re-opened | 17:46 |
| pmjdebru1jn | Chroot support is now available in Upstart 1.3. | 17:49 |
| pmjdebru1jn | hmmm | 17:49 |
| pmjdebru1jn | https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverviewUpstart | 17:50 |
| 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:51 |
| 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:58 |
| 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 | 17:59 |
| 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:00 |
| 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:12 |
| 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:13 |
| jMCg | . | 18:18 |
| JanC | starting the job doesn't work? | 18:20 |
| jMCg | JanC: nope, hangs the same as stop logstash | 18:23 |
| 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:24 |
| 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:27 |
| 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:29 |
| jMCg | Yeah, but I'd rather not :P | 18:31 |
| jMCg | Well, that still doesn't quite help me with the start/stop that doesn't start/stop :-/ | 18:32 |
| jMCg | /proc/self/fd/9: 2: /proc/self/fd/9: setuid: not found | 18:42 |
| SpamapS | jMCg: if you have a process listed that isn't running, you set 'expect fork' incorrectly | 18:53 |
| jMCg | SpamapS: yeah, and how do I fix it, other than rebooting the machine? | 18:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| SpamapS | jMCg: probably | 18:59 |
| SpamapS | jMCg: I wrote it as python3 as part of my "getting used to python 3" experiment :) | 18:59 |
| jMCg | SpamapS: how often/long will it have to run? | 19:02 |
| 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:04 |
| 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:05 |
| SpamapS | ahh wrong place | 19:07 |
| 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:08 |
| jMCg | SpamapS: yeah, but that's not so much the issue as the setuid stuff ;) | 19:09 |
| jMCg | ah | 19:10 |
| jMCg | root stanzas, now I see | 19:10 |
| jMCg | SpamapS: but the chdir is not? | 19:10 |
| 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:11 |
| SpamapS | unless there's some important reason that it might be there instead | 19:12 |
| jMCg | SpamapS: nope. There is not. | 19:19 |
| 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:35 |
| jMCg | SpamapS: but env cannot be a file. | 19:48 |
| 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:54 |
| thinkingpotato | SpamapS: thanks for the answer, so approach such as http://askubuntu.com/a/4413 could give me some results? | 19:58 |
| jMCg | SpamapS: where's the init(5)'s source? | 20:21 |
| jMCg | found. | 20:21 |
| 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? | 20:26 |
| === alienth is now known as itsthecops | ||
| === itsthecops is now known as alienth | ||
| pmjdebru1jn | JanC: btw just tested, dpkg-divert practically solved my problem | 21:03 |
| thinkingpotato | 10 hours later: that was a wrong uid/gid I started with... problem solved, works like charm | 21:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!