=== sadmac_ is now known as sadmac [20:59] 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] Upstart depends on being pid 1 [20:59] and it expects the special behaviour afforded that process by the kernel [21:00] 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] 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] Maybe the solution is to try yet another hosting provider.. [21:03] pid 2 would not have daemon process children reparented to it [21:03] which has always been a specific goal of upstart's to support [21:04] Hmm I think I have to dive into some documentation first to understand that. [21:05] why can you not replace the existing pid #1 ? [21:06] 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] why don't you have control over it? [21:07] because cat /proc/1/exe results in permission denied. I don't where the file is. It's a virtual server. [21:08] 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] If a process starts another doesn't the kernel setup a parent -> child relation automatically? [21:09] surely you have control over the distribution you installed? [21:10] Keybuk All files but /dev/* I can't mknod [21:10] I can start a repair system. This way I can access /vserver containing all files. [21:10] you're a nixos developer? [21:11] 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] 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] are you attempting to replace sysvinit in nixos with Upstart? [21:13] nixos has been using upstart-0.3 for years [21:13] and when installed into a vserver, its pid isn't 1? [21:13] Eelco (core developper) told me he wants to start an upstart-0.5.1 branch now [21:13] I don't know how to tell the vserver to run upstart at all :-( [21:14] :-/ [21:14] * Keybuk has heard of problems with vserver before [21:14] I've had arguments with vserver upstream in fact [21:14] over things like vserver failing to provide init with the special signal handling it expects [21:14] which suggests that you can run upstart as init/pid #1 in a vserver [21:15] 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] MarcWeber: supervision of daemon processes [21:17] 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] Reparenting = if a daemon dies its subprocesses are reparented to be direct childs of init so that init (upstart) can kill them ? [21:36] exactly [21:36] and more to the point [21:36] so init (upstart) is notified when they die [21:37] 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] no, more than that [21:38] upstart will never know that pid 10 has exited [21:38] It could try to find pid 10 10 times a sec.. [21:38] eew. [21:38] But that's no option. [21:39] So I'll look for yet another hosting service.. [21:41] 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] today is not a good day [21:43] rgr [21:50] What's wrong with waitpid to get notified when a child terminates? [21:51] MarcWeber: only tells you /your/ children. we need to know about the /daemon/'s children. grandkids [21:52] Ok. Then I was right. [21:57] sadmac2: ok, let's look at your patch ;) [21:58] Keybuk: err... its kind of at home and in pieces. I was hoping to do it in about an hour :) [21:58] can I tell you my mad idea first? [21:58] ghead [22:07] Keybuk: still here? [22:09] yup [22:09] so you know how "initctl start" and "initctl stop" are just commands that muck around with the job state directly [22:09] what if they weren't? [22:09] by that I mean [22:09] if I do "stop somejob", the job stops [22:09] and if I reboot [22:09] the job is still stopped [22:09] and if I do "start someotherjob" to make a new copy [22:09] when I reboot, that is started again [22:11] Keybuk: how do you handle single user mode? [22:11] no plans there [22:12] 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] Keybuk: actually, it could work. [22:28] 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] so its just a matter of making /etc/init/enabled_services_foo-mode /var/lib/*/enabled_services_foo-mode [22:29] well [22:30] that's basically what I was thinking [22:30] start would add a file in /var/lib/init that morally said that the particular instance should be auto-started [22:30] (assumedly it was manual before) [22:30] stop would add a file saying that it should not be auto-started [22:30] start 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] I assume one would add and one would remove :) [22:42] What actually happens when a child of a daemon exits? [22:43] MarcWeber: if the daemon is still running, then nothing. [22:45] MarcWeber: if the daemon dies, then its children get inherited by pid 1 (always pid 1, whatever that may be). [22:46] sadmac2: Example: mysqld dies but has still one serving process. What should happen? (same for apache or such) [22:46] of course the daemon should be restarted. [22:47] MarcWeber: they get reparented to pid 1, which may then wait on them [22:48] When does upstart get to know about them? Whet those daemon child processes are created or when the daemon dies? [22:49] 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] 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] a service is considered dead by upstart when it has no more processes. [22:51] so a traditional init does restart services to early. [22:52] a traditional init doesn't restart them at all :) [22:52] well it can, but for most larger things it doesn't [23:12] 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] Keybuk: I'm at home now. still interested in this code/having mad ideas? [23:26] sadmac: sure [23:31] Keybuk: http://sadmac.fedorapeople.org/parse_job.y [23:31] 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] then we get some makefile.am changes and some changes to the test cases to account for the slightly altered error reporting. [23:32] slightly altered? [23:33] most errors end up turning into UNEXPECTED_TOKEN the way things are written. This can change though. [23:33] (unfortunate part about that error, when isn't it true?) [23:35] right, I think I ran across that before with bison [23:35] I notice you're having token issues there [23:35] isn't it normal to use flex to write the lexer/tokeniser then pass that to bison? [23:36] I kinda figured the lexer would be too simple to bother. Oops. :) [23:36] is there any bits of syntax that are "hard" to do this wya? [23:36] context-sensitive keywords [23:37] how so? [23:37] 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] isn't that just [23:38] 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] start_on := "start" "on" EVENTTREE [23:38] EVENTTREE := "event" | EVENTTREE "or" EVENTTREE | EVENTTREE "and" EVENTTREE [23:38] 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] err s/"event"/EVENT/ [23:38] EVENT := NAME ARG* [23:39] heh, pythonic parens ;) [23:39] randomly [23:39] it's probably quite easy to parse the syntax in lua ;) [23:39] ugh. lua is scary. [23:39] that doesn't solve it [23:39] what type is NAME? [23:40] that's a type [23:40] when you say "start" in bison, you declare a new type. a token with name "start" is of type "start" [23:40] it can be a bare word, or a single or double-quoted string [23:40] ARG is the same [23:40] so what we [23:40] what we'd need is a line like this [23:41] STR := LITERAL_TOKEN | "start" { $$ = "start" } | "on" { $$ = "on" } | "stop"..... [23:42] the easier, and better option is to just say "keywords are keywords" and make users quote them. [23:42] how do you mean? [23:42] start on start --> syntax error [23:42] start on "start" --> ok [23:42] that third one can't be start [23:42] it's not at the start of a line [23:43] keywords only appear at the beginning of a line [23:43] Keybuk: the problem is the type [23:43] Keybuk: when "start" appears in the bison grammar, that isn't a string [23:43] that is a "start". [23:43] its its own type [23:43] surely type depends on context? [23:44] not for tokens [23:44] not for the output of the lexer [23:44] you can create the hierarchy, but its a lot of text. [23:44] because each keyword is a different type. There's no way to apply the promotion to them categorically. [23:45] remember, when the lexer sees "start" it has to decide what type it is [23:45] that sucks ;) [23:45] and the lexer doesn't maintain state other than file position. it has no idea what came before [23:46] 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] what's the difference in resulting code though? [23:47] and any difference in speed? [23:47] didn't look in difference in resulting code. speed seems uncanny. tests run faster than my terminal can write the results. [23:49] 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