[00:33] <MFen> what's the workaround for stopping an upstart job that had expect daemon and now cannot be stopped?
[00:33] <MFen> i.e. didn't start in the first place, but upstart thought it did
[00:36] <MFen> also i'm having serious doubts about whether chdir does anything
[02:13] <SpamapS> MFen: if it has a pid that is actually gone when you type 'status jobname' then you have to exhaust the pid space and then let upstart kill the pid listed there
[02:13] <SpamapS> MFen: chdir works, Its used in quite a few jobs
[02:14] <MFen> yeah the whole job was a problem
[02:14] <MFen> i discovered the exec 2>>/dev/.initramfs/foo.log trick though. fixed things right up
[02:14] <MFen> just unexpected missing env vars
[14:08] <viric> Hello
[14:09] <viric> I've an upstart deadlocking at boot in a select(), according to strace.
[14:09] <viric> the last thing it does is: 1     write(8, "<6>init: Handling startup event\n", 32) = 32
[14:09] <viric> (before deadlocking into the select)
[14:11] <viric> I notice it doesn't read any file inside /etc/init, too
[15:17] <SpamapS> viric: what OS? What version of upstart?
[15:20] <viric> nixos, upstart 1.5, mips-n64
[15:20] <viric> sorry
[15:20] <viric> mips-n32
[15:20] <viric> keeping same libnih, same upstart, I can boot with linux 3.4.2, and can't boot with linux 3.6.4
[15:21] <viric> I'll try to find if I'm missing any component, by trying back to have a linux 3.4.x, but keeping all userland the same.
[15:21] <viric> '--debug' doesn't show anything beyond '--verbose' either.
[15:21] <viric> And with strace, I can see that it adds a watch for /etc/init, but it doesn't read any conf file.
[15:22] <viric> SpamapS: the same versions boot fine in x86_64 and i686.
[15:28] <SpamapS> viric: jodh and slangasek are likely busy travelling home from UDS in Copenhagen right now, so you may have a hard time getting an answer from them, and they're probably the best ones to ask this question of
[15:28] <SpamapS> viric: it does sound, however, that perhaps the kernel changed something as well
[15:28] <slangasek> not traveling today, still stuck in CPH ;)
[15:29] <slangasek> viric: do you have inotify support in your 3.6 kernel?
[15:30] <slangasek> or perhaps inotify is broken on mips in 3.6?
[15:30] <viric> Yes, INOTIFY is there
[15:30] <SpamapS> slangasek: joy! ;)
[15:30] <viric> It'll take me some time to build a 3.4; but I'll report once I try it
[15:32] <slangasek> so it does sound like a kernel bug/issue to me
[15:32] <slangasek> the upstart code is bog simple
[15:33] <viric> I'll paste the strace
[15:33] <viric> http://sprunge.us/UJHR  that's stracing "-f -p 1" before execing init
[15:34] <viric> I don't know inotify userland tools, to test that
[18:23] <viric> slangasek: tested. 3.4.16 boots. 3.6.4, upstart deadlock
[19:39] <JanC> viric: are you sure it deadlocks?
[19:43] <JanC> I don't know much about upstart's internals, but I think "handling startup event" should happen *after* reading the files inside /etc/init/ ?
[19:44] <viric> it doesn't read the files
[19:44] <viric> JanC: look at the strace: http://sprunge.us/UJHR
[19:44] <viric> it doesn't go beyond.
[19:45] <viric> but I see it happening in 3.6.4, not in 3.4.2 or 3.4.16
[19:45] <JanC> logically speaking, I'd think it can't handle any events before reading those files, but I might be entirely wrong  ;)
[19:46] <viric> yes, I think that the inotify should tell upstart about the files, and upstart would read them. But that does not happen. The inotify fds are in the select 'read' list, but nothing goes on.
[19:46] <viric> Someone broke linux mips, I think.
[19:47] <JanC> I guess you'll have to wait for some of the developers to help find out
[19:47] <viric> Let's see if someone thinks the same at linux-mips; I mailed them already.
[19:47] <JanC> well, if it's just inotify that broke on MIPS, there are Python and maybe Perl etc. bindings for that
[19:47] <viric> I could learn some inotify userland tools to demonstrate the failure closer to kernel syscalls, but I'll wait for some first answer from them
[19:48] <viric> I don't have a very nice boot with those kernels, due to the upstart failure, though. :)
[19:48] <JanC> you can always boot with a shell  ☺
[19:49] <JanC> oh, and there is this a script from one of the upstart developers that gives you a menu to select an "init"
[19:51] <JanC> http://people.canonical.com/~jhunt/upstart/utils/
[19:52] <JanC> might be helpful while testing this and possible fixes  ☺
[19:52] <viric> JanC: sure, I boot with a shell, that's what I do.
[19:52] <viric> no trouble. :)
[19:53] <viric> JanC: or how do you think I straced PID 1, and detached? :)
[19:58] <JanC> there are all sorts of weird things one can do, but maybe that script is still useful  ☺
[20:32] <viric> choosing an init is quite easy having grub. It only requires to type 'e' at the menu option, and add init=PROGRAM before boot.
[21:08] <JanC> viric: sure, if you have it configured to show the menu
[21:11] <JanC> you could implement a similar menu with grub anyway
[21:11] <viric> yep
[21:16] <JanC> viric: is upstart the default init on NixOS or just an option?
[21:17] <viric> the default since long long
[21:17] <viric> but the switch to systemd will happen some day soon
[21:19] <JanC> because that is easier to maintain?
[21:21] <viric> because the people who do the work are the people who decide ;)
[21:21] <viric> I'd personally have stayed at sysvinit ;)
[21:22] <JanC> I think sysvinit isn't exactly ideal
[21:22] <viric> I don't get much this dbus world, with consolekit, polkit, etc.
[21:22] <JanC> dbus is just an IPC mechanism
[21:23] <viric> yes, a too flexible piece.
[21:23] <viric> then there come a whole new namespace rules to respect
[21:23] <viric> and learn
[21:24] <viric> we have the filesystem, we have the network, then dbus, ... too much for my simple mind
[21:24] <JanC> greater flexibility & greater possibilities usually come with greater complexity & more to learn indeed  :-/
[21:25] <viric> yes. For me, the overall ratio of advantadges/drawbacks isn't >1.
[21:25] <viric> Both for upstart and systemd. In fact, I've not learnt systemd at all, but I expect the worse :)
[21:26] <viric> I prefer to give up on "parallell starting of daemons", and have simpler but slower pieces.
[21:26] <viric> I can accept a longer boot too. :)
[21:27] <JanC> well, that might be sure for certain servers and workstations maybe
[21:27] <JanC> but most people don't want a 2 minute boot on to check what 2 mail messages they got today  ;)
[21:29] <viric> bah, I pm-suspend always
[21:30] <JanC> "eternal suspend/resume" that would be nice if various desktop applications wouldn't leak memory like hell
[21:58] <viric> I do restart those ;)
[21:58] <viric> but xterm, ssh, irssi, mutt, and other pieces I've written, don't leak enough :)
[22:34] <JanC> my current problemetaic piece of software is natu
[22:34] <JanC> *nautilus
[22:34] <JanC> but that's another story (not on-topic for this channel)