[20:59] <MarcWeber> Does it make sense to you introducing init --expected-pid=2 ? Why? I'm trying to run nixos on a vserver. I can't replace the default init so I have to run upstart using PID 2. Of course I can patch those two lines. But maybe other people do have this problem as well ?
[20:59] <Keybuk> Upstart depends on being pid 1
[20:59] <Keybuk> and it expects the special behaviour afforded that process by the kernel
[21:00] <MarcWeber> That's bad news. the vserver even starts without /sbin/init.. So I can't change that so I can't use upstart without heavy patching?
[21:02] <MarcWeber> Keybuk: can you estimate the amount of work required to make this possible? I mean a PID 2 should be able to run jobs as well. (Maybe its killed by PID3 .. I think I must live with that..)
[21:03] <MarcWeber> Maybe the solution is to try yet another hosting provider..
[21:03] <Keybuk> pid 2 would not have daemon process children reparented to it
[21:03] <Keybuk> which has always been a specific goal of upstart's to support
[21:04] <MarcWeber> Hmm I think I have to dive into some documentation first to understand that.
[21:05] <Keybuk> why can you not replace the existing pid #1 ?
[21:06] <MarcWeber> Cause I don't have control over pid #1. All it seems I can do is providing runlevel code. And thats pid > 1. But can send another ticket to clarify that..
[21:06] <Keybuk> why don't you have control over it?
[21:07] <MarcWeber> because cat /proc/1/exe  results in permission denied. I don't where the file is. It's a virtual server.
[21:08] <MarcWeber> Or do you have any idea how to find the location other then find . -name "init" (which showed only /sbin/init which isn't executed at all)
[21:09] <MarcWeber> If a process starts another doesn't the kernel setup a parent -> child relation automatically?
[21:09] <Keybuk> surely you have control over the distribution you installed?
[21:10] <MarcWeber> Keybuk All files but /dev/* I can't mknod
[21:10] <MarcWeber> I can start a repair system. This way I can access /vserver containing all files.
[21:10] <Keybuk> you're a nixos developer?
[21:11] <MarcWeber> When do you call somone a developer? I've been a contributor for over a year now. I haven't written much of the core C(++) code though.
[21:12] <MarcWeber> And we already talked about a similar problem a year ago. That time I tried setting up upstart-0.5. I had to patch it cause the other hosting used a kernel not providing a feature..
[21:12] <Keybuk> are you attempting to replace sysvinit in nixos with Upstart?
[21:13] <MarcWeber> nixos has been using upstart-0.3 for years
[21:13] <Keybuk> and when installed into a vserver, its pid isn't 1?
[21:13] <MarcWeber> Eelco (core developper) told me he wants to start an upstart-0.5.1 branch now
[21:13] <MarcWeber> I don't know how to tell the vserver to run upstart at all :-(
[21:14] <Keybuk> :-/
[21:14]  * Keybuk has heard of problems with vserver before
[21:14] <Keybuk> I've had arguments with vserver upstream in fact
[21:14] <Keybuk> over things like vserver failing to provide init with the special signal handling it expects
[21:14] <Keybuk> which suggests that you can run upstart as init/pid #1 in a vserver
[21:15] <MarcWeber> Keybuk: Can you tell me briefly why I want this reparenting or can you give me some keywords so that I can google it up?
[21:15] <Keybuk> MarcWeber: supervision of daemon processes
[21:17] <MarcWeber> The first hosting provider lets me use /sbin/init. The trouble is that I can't use recent coreutils. That means that all software packages hashes would change. This means I can neither use nor provide binary packages.. So I know that some vservers can use #1.
[21:25] <MarcWeber> Reparenting = if a daemon dies its subprocesses are reparented to be direct childs of init so that init (upstart) can kill them ?
[21:36] <Keybuk> exactly
[21:36] <Keybuk> and more to the point
[21:36] <Keybuk> so init (upstart) is notified when they die
[21:37] <MarcWeber> So that it can restart the process. looking out wether a pid 10 still exists won't work cause the kernel might have given pid 10 to another process ?
[21:38] <Keybuk> no, more than that
[21:38] <Keybuk> upstart will never know that pid 10 has exited
[21:38] <MarcWeber> It could try to find pid 10 10 times a sec..
[21:38] <sadmac2> eew.
[21:38] <MarcWeber> But that's no option.
[21:39] <MarcWeber> So I'll look for yet another hosting service..
[21:41] <sadmac2> Keybuk: I have a good chunk of a replace-nih-config-with-bison patch. Its pretty ratty but worth a guided tour. How long will you be around today?
[21:42] <Keybuk> today is not a good day
[21:43] <sadmac2> rgr
[21:50] <MarcWeber> What's wrong with waitpid to get notified when a child terminates?
[21:51] <sadmac2> MarcWeber: only tells you /your/ children. we need to know about the /daemon/'s children. grandkids
[21:52] <MarcWeber> Ok. Then I was right.
[21:57] <Keybuk> sadmac2: ok, let's look at your patch ;)
[21:58] <sadmac2> Keybuk: err... its kind of at home and in pieces. I was hoping to do it in about an hour :)
[21:58] <Keybuk> can I tell you my mad idea first?
[21:58] <sadmac2> ghead
[22:07] <sadmac2> Keybuk: still here?
[22:09] <Keybuk> yup
[22:09] <Keybuk> so you know how "initctl start" and "initctl stop" are just commands that muck around with the job state directly
[22:09] <Keybuk> what if they weren't?
[22:09] <Keybuk> by that I mean
[22:09] <Keybuk> if I do "stop somejob", the job stops
[22:09] <Keybuk> and if I reboot
[22:09] <Keybuk> the job is still stopped
[22:09] <Keybuk> and if I do "start someotherjob" to make a new copy
[22:09] <Keybuk> when I reboot, that is started again
[22:11] <sadmac2> Keybuk: how do you handle single user mode?
[22:11] <Keybuk> no plans there
[22:12] <sadmac2> I think you might be having those "neat when everything's running normally" type ideas. Hard to bootstrap, hard to deal with in an inconsistent state.
[22:27] <sadmac2> Keybuk: actually, it could work.
[22:28] <sadmac2> Keybuk: so things like single user mode would be done by just specifying which set of enabled services you want on the command line (out of a series of configured choices). start/stop would affect whichever was active
[22:29] <sadmac2> so its just a matter of making /etc/init/enabled_services_foo-mode /var/lib/*/enabled_services_foo-mode
[22:29] <Keybuk> well
[22:30] <Keybuk> that's basically what I was thinking
[22:30] <Keybuk> start <instance> would add a file in /var/lib/init that morally said that the particular instance should be auto-started
[22:30] <Keybuk> (assumedly it was manual before)
[22:30] <Keybuk> stop <instance> would add a file saying that it should not be auto-started
[22:30] <Keybuk> start <creating a new instance> would create a new job file in /var/lib/init for the new instance, specifying the conditions in which it runs (from the cmdline)
[22:31] <sadmac2> I assume one would add and one would remove :)
[22:42] <MarcWeber> What actually happens when a child of a daemon exits?
[22:43] <sadmac2> MarcWeber: if the daemon is still running, then nothing.
[22:45] <sadmac2> MarcWeber: if the daemon dies, then its children get inherited by pid 1 (always pid 1, whatever that may be).
[22:46] <MarcWeber> sadmac2: Example: mysqld dies but has still one serving process. What should happen? (same for apache or such)
[22:46] <MarcWeber> of course the daemon should be restarted.
[22:47] <sadmac2> MarcWeber: they get reparented to pid 1, which may then wait on them
[22:48] <MarcWeber> When does upstart get to know about them? Whet those daemon child processes are created or when the daemon dies?
[22:49] <MarcWeber> I'm trying to figure out wether I neet this upstart feature or not. I mean a lot of distributions still do use a traditional init..
[22:49] <sadmac2> at the moment never :) upstart just sees them as wayward userspace processes when it inherits them. Working with kernel folks on a solution (0.5.* uses ptrace to monitor the daemon as it runs and capture its calls to fork() thus finding out that way)
[22:50] <sadmac2> a service is considered dead by upstart when it has no more processes.
[22:51] <MarcWeber> so a traditional init does restart services to early.
[22:52] <sadmac2> a traditional init doesn't restart them at all :)
[22:52] <sadmac2> well it can, but for most larger things it doesn't
[23:12] <MarcWeber> sadmac2: I've tried it. apache is not restarted if you kill it. However writing a wget /curl cron job test running apachectl {stop,start} would take me less than a minute.
[23:12] <sadmac> Keybuk: I'm at home now. still interested in this code/having mad ideas?
[23:26] <Keybuk> sadmac: sure
[23:31] <sadmac> Keybuk: http://sadmac.fedorapeople.org/parse_job.y
[23:31] <sadmac> I don't seem to have the ignore rules right to get it to not look at generated files and otherwise do what it should, but basically that replaces parse_job.c
[23:32] <sadmac> then we get some makefile.am changes and some changes to the test cases to account for the slightly altered error reporting.
[23:32] <Keybuk> slightly altered?
[23:33] <sadmac> most errors end up turning into UNEXPECTED_TOKEN the way things are written. This can change though.
[23:33] <sadmac> (unfortunate part about that error, when isn't it true?)
[23:35] <Keybuk> right, I think I ran across that before with bison
[23:35] <Keybuk> I notice you're having token issues there
[23:35] <Keybuk> isn't it normal to use flex to write the lexer/tokeniser then pass that to bison?
[23:36] <sadmac> I kinda figured the lexer would be too simple to bother. Oops. :)
[23:36] <Keybuk> is there any bits of syntax that are "hard" to do this wya?
[23:36] <sadmac> context-sensitive keywords
[23:37] <Keybuk> how so?
[23:37] <sadmac> for example, with nih_config "start on start" is valid. the second start isn't a keyword anymore, it becomes an event name.
[23:37] <Keybuk> isn't that just
[23:38] <sadmac> its very doable, the problem is it can't be done categorically. every keyword needs a (one line) mention that it promotes to string when asked.
[23:38] <Keybuk> start_on := "start" "on" EVENTTREE
[23:38] <Keybuk> EVENTTREE := "event" | EVENTTREE "or" EVENTTREE | EVENTTREE "and" EVENTTREE
[23:38] <sadmac> the other thing that was hard was allowing event operators to have linebreaks BUT only inside parenthesis. My solution to that isn't final
[23:38] <Keybuk> err s/"event"/EVENT/
[23:38] <Keybuk> EVENT := NAME ARG*
[23:39] <Keybuk> heh, pythonic parens ;)
[23:39] <Keybuk> randomly
[23:39] <Keybuk> it's probably quite easy to parse the syntax in lua ;)
[23:39] <sadmac> ugh. lua is scary.
[23:39] <sadmac> that doesn't solve it
[23:39] <sadmac> what type is NAME?
[23:40] <Keybuk> that's a type
[23:40] <sadmac> when you say "start" in bison, you declare a new type. a token with name "start" is of type "start"
[23:40] <Keybuk> it can be a bare word, or a single or double-quoted string
[23:40] <Keybuk> ARG is the same
[23:40] <sadmac> so what we
[23:40] <sadmac> what we'd need is a line like this
[23:41] <sadmac> STR := LITERAL_TOKEN | "start" { $$ = "start" } | "on" { $$ = "on" } | "stop".....
[23:42] <sadmac> the easier, and better option is to just say "keywords are keywords" and make users quote them.
[23:42] <Keybuk> how do you mean?
[23:42] <sadmac> start on start --> syntax error
[23:42] <sadmac> start on "start" --> ok
[23:42] <Keybuk> that third one can't be start
[23:42] <Keybuk> it's not at the start of a line
[23:43] <Keybuk> keywords only appear at the beginning of a line
[23:43] <sadmac> Keybuk: the problem is the type
[23:43] <sadmac> Keybuk: when "start" appears in the bison grammar, that isn't a string
[23:43] <sadmac> that is a "start".
[23:43] <sadmac> its its own type
[23:43] <Keybuk> surely type depends on context?
[23:44] <sadmac> not for tokens
[23:44] <sadmac> not for the output of the lexer
[23:44] <sadmac> you can create the hierarchy, but its a lot of text.
[23:44] <sadmac> because each keyword is a different type. There's no way to apply the promotion to them categorically.
[23:45] <sadmac> remember, when the lexer sees "start" it has to decide what type it is
[23:45] <Keybuk> that sucks ;)
[23:45] <sadmac> and the lexer doesn't maintain state other than file position. it has no idea what came before
[23:46] <sadmac> Keybuk: it does... but then I could put that in and several other things and all this would still be less code than the old parse_job.c. AND there'd be no more nih_config
[23:46] <Keybuk> what's the difference in resulting code though?
[23:47] <Keybuk> and any difference in speed?
[23:47] <sadmac> didn't look in difference in resulting code. speed seems uncanny. tests run faster than my terminal can write the results.
[23:49] <sadmac> the resulting code isn't that interesting here, since you never read it. they put in all the #line macros so the errors are reported against the original .y