=== wasabi_ [n=wasabi@cpe-76-184-122-13.tx.res.rr.com] has joined #upstart === jonibo [n=jonas@ua-83-227-144-18.cust.bredbandsbolaget.se] has joined #upstart === AlexExtreme wonders if NihHash would be a better storage type for the list of profile entries === Md [i=md@freenode/staff/md] has joined #upstart === AlexExtreme [n=AlexExtr@frugalware/developer/AlexExtreme] has joined #upstart === rgl [n=Rui@84.90.10.107] has joined #upstart [01:12] hi [01:13] AlexExtreme, why is this """When a job is disabled by the current profile, it still responds to events, it'll just not actually start. If the system is currently in a state when it can be running, and the profile is changed to one which allows it to be run, it'll start.""" ? [01:13] why to refuse to start a job? [01:13] because that's what disabling a job is? [01:13] I mean, if the admin wants to start a job that is not in the current profile, why should he be refrained from starting it anyways? === Keybuk [n=scott@wing-commander.netsplit.com] has joined #upstart [01:14] for me "disabling" is "disabling the service from being automatically started" [01:14] rgl, it would only be disallowed from starting if the profile specifically states that that job is disabled, and even then it could still be started manually [01:15] yes, I understood that. what I don't understant is why :D [01:15] "why you want to do that" [01:15] for me "disabling" is "disabling the service from being automatically started" [01:15] that's exactly what it does... [01:15] sounds like you're both arguing for the same thing :) [01:15] you can still start it manually [01:16] ah :-) [01:16] sorry for the confusion :D [01:18] that makes the most sense to me as well [01:18] "disabled" jobs don't react to events, but still show up in lists, and can still be manually started/stopped [01:20] yeah [01:29] hmm [01:31] in terms of profiles, i'll be doing lookups by name quite often, both when parsing a profile and starting a job. so a hash would be more efficient [01:31] and i hadn't thought of using wildcards for job name matching. hrm [01:41] ah, so my email has something useful? :-) [01:42] yep :p [01:55] the interesting thing about Profiles, compared to the original Flags idea, is that Profiles are defined separately to Jobs [01:55] for Flags, the idea was that a Job listed the states it was enabled/disabled in [01:55] the thing I like about Profiles is that it's up to the sysadmin how Jobs are grouped [01:55] yes [01:55] IMO it's much more flexible [01:56] so this has got me thinking a bit [01:56] Profiles are fundamentally groups of Jobs [01:56] "these are the jobs that do things with networking" [01:56] "these are the jobs that do multi-user things" [01:56] "these are the jobs when the machine is acting as a web-server" [01:57] (I often used runlevel 3 in sysvinit for the latter, so I could turn on/off apache/postgresql/etc. which were expensive to run) [01:58] does that sound kinda right? [01:58] yeah [01:59] an interesting side-effect of the "disable means no auto-start" functionality is that if you disabled udev, then you inherently disable all jobs that react to udev events [01:59] so that's quite nice [02:01] can we please have multiple profiles active? :D [02:01] though, that goes against the word "profile", so maybe we should have job groups *G* [02:02] ("job groups" the name) [02:02] side note: i noticed the kbdrequest event earlier - what exactly is it useful for? [02:06] AlexExtreme: I think it's supposed to be "spawn a new getty" *shrug* [02:06] rgl: yeah, that's what I've been thinking [02:06] since a Profile basically acts as a group of Jobs [02:06] maybe we don't need to specify enable/disable in a profile [02:07] instead it just needs to include jobs by name [02:07] and then you can enable/disable a profile [02:07] this profiles idea gets more complicated by the day *g* [02:08] and have a directory with all the jobs in the profile (instead of a file; like I've said some of this day hehe) *G* [02:08] no [02:08] i will never, ever have that. it'd be a complete mess. we might as well just go back to /etc/rc*.d... [02:08] rgl: why would a directory be good? then a job couldn't be in multiple profiles [02:09] that'd be possible, of course, with nice symlinks all over the place [02:09] AlexExtreme: well, if a profile is just a list of jobs, and enabled/disabled, you just need to check whether any of the profiles the job is listed in are disabled [02:09] eww, symlinsk [02:09] symlinks are evil as a configuration mechanism [02:10] you chould just touch the file. [02:10] (no symlink) [02:10] empty files? [02:10] that's just as bad [02:10] there'd be still little files everywhere [02:10] very djb-ish [02:11] yeah [02:11] that's what i hated with djb/runit :P [02:11] djb-ish is good for ya! [02:11] I love it :D [02:11] service == directory and scripts/files inside [02:11] why not just one file? [02:12] my Profiles musing went a bit further ,.. [02:12] if a profile is a list of jobs, and if a profile can be disabled or enabled [02:12] its easier to admin using regular CLI tool? touch/rm vs using a command to parse the file and do that. [02:12] then you could link profiles to a state [02:13] rgl, how is it easier? it'd be a complete nightmare for the distro developers [02:13] AlexExtreme, nightmare? why? [02:13] touch vs vi is pretty even [02:14] the modify command approach is better, since it can guarantee integrity [02:14] (what is the behaviour if you touch the name of a job that doesn't exist?) [02:14] Keybuk, its the same has using vi and inserting it in the profile file ;) [02:15] rgl: exactly, there's no admin difference [02:16] Keybuk, there is. to enable a service you have to use upstart-profile-enable-service service vs touch something [02:16] ? [02:16] no, you can use vi [02:17] or easier: [02:17] echo "enable myjob" >> /etc/init/profiles.d/myprofile [02:17] Keybuk, why did debian decide to use enabled-sites/ directories instead of using "Include" in the file? [02:17] AlexExtreme, and to remove? :D [02:18] sed -i '/enable myjob/d' /etc/init/profiles.d/myprofile [02:18] AlexExtreme, my point is, you have to use a command for doing it. but its a mater of taste *shrug* [02:18] AlexExtreme, obsioly, thats not that simple. [02:19] you have to use a command if you've got directories too [02:19] AlexExtreme, you have to skip comments, etc. [02:20] lets not paint the bikeshed anymore ;-) [02:20] rgl: how do you comment out the disabling of a service with your method? [02:22] Keybuk, humm, I was not thinking of disabling jobs. this was a "enable only" thing. if you want to disable the job, just rm the job from the profile. [02:22] take this as an example: [02:22] if a distro developer provided a job with a package and wanted that job enabled in all profiles by default [02:22] they'd have to go through each profile and add it in [02:23] rgl: no, I just want to comment it out for a while [02:23] you can't do that with the file technique [02:23] and you can't document why it's removed [02:23] # keybuk - think this is breaking networking - 02jun07 [02:23] surely it would be easier to just put it in /etc/event.d or whatever and have the profile "enable/disable *" lines handle it [02:23] # ntpdate [02:24] AlexExtreme, document? use a automated thing to administer your box? :D [02:24] err [02:24] that was for Keybuk :D [02:25] huh? [02:25] what has an "automated thing" got to do with anything? [02:25] AlexExtreme, with the "document" part that Keybuk said. [02:26] i still don't get what it's got to do with that [02:26] brb, lunch [02:27] anyway, it's my bikeshed, and we're using configuration files; not directories-o-symlinks or djb madness [02:27] I was just saying that the "document" part could be addressed by your automated tool. (if you don't use one, yeah, it sux, and you can't document) [02:28] you can't document in the model you suggest though [02:28] Keybuk, fair enough :-) [02:28] you'd need another directory of documents about why things aren't in another one [02:55] btw Keybuk, it'd make sense to put all the profile stuff into a seperate source file (like profile.{c,h}) rather than sticking it onto the parsing stuff in cfgfile.c, right? if i were to put it in cfgfile.c it'd allow you to put job stanzas in profiles and vice-versa, which isn't what i want, really ;) [03:26] it should have a separate stanzas list, yes [03:26] k [03:28] that file is a little mixed up [03:28] since it has the parsing and watching code too [03:28] (which should be shared) === juergbi [n=juerg@80-219-16-162.dclient.hispeed.ch] has joined #upstart === __keybuk [n=scott@wing-commander.netsplit.com] has joined #upstart [03:43] hmm, profile.c written. now to plug it in to the rest of upstart ;) === Keybuk keeps hitting namespace problems [03:49] with what? [03:50] right now we're relying on the filesystem to provide the namespace [03:50] if we allow people to define multiple jobs in one file, how do we enforce that? [03:50] (likewise for profiles) [03:51] hmm [03:55] obviously we have to solve this if we want people to be able to register jobs over the initctl socket [03:55] i'm not quite sure i understand [03:55] well [03:55] let's say I make /etc/init/jobs.d/foo [03:56] and I also make /etc/init/upstart.conf and put [03:56] job foo [03:56] ... [03:56] end foo [03:56] in it [03:56] which gets priority? [03:56] (and how do we stop them both fighting) [03:56] hrm [03:57] i would say the one in upstart.conf gets priority [03:57] take this as an example: [03:57] so the first one parsed? [03:57] a distribution provides a job called foo, and the user wants to override that job with their own version without editing the one provided by their distro [03:57] (assuming upstart.conf is registered first) [03:58] they could put their version in upstart.conf [03:58] and it would get priority [03:58] ok, and self-registered would take priority over that? [03:58] they could easily revert to the distros version by simply commenting out their version [03:58] yes [03:58] that makes it easy then [03:58] a Job just needs to know which CfgSource it was registered with [03:58] and when loading a job from a source, check the source is the same [03:59] though this means you can't move a job from one source to another [03:59] if you delete /etc/init.d/upstart.conf, the jobs.d/foo one wouldn't show up unless touched [04:00] it's not that big a problem, and if it could be solved by touching the other one, then it's a minor problem [04:00] I'd prefer it to be solved internally [04:01] we'd need a JobName structure that tracked, for a given name, what was available from each source, and whether each of those things had replacements [04:06] that's a bit sucky, since we'd need the same for Profile and State === rgl_ [n=Rui@84.90.10.107] has joined #upstart [05:42] hmm [05:43] say a job has been disabled in a profile, yet the sysadmin has started it manually. should the job respond to stop events? [05:54] I think it should. [05:54] me too [05:56] yes [05:56] profiles should just affect start events [05:56] cf. job is running, and sysadmin disables the profile, it should still stop later [05:57] maybe it should stop immediately too === Keybuk tries to come up with a sensible filename for "job definition parsing" [06:01] in theory, we should be able to use the same pattern for "state definition" and "profile definition" [06:08] you mean source file name? [06:09] yeah [06:10] parser.c ? :P [06:11] doesn't say "job" though [06:11] so we'd have to put state and profile parsing in the same file [06:12] jobparse.c [06:13] and stateparse.c and profileparse.c ? [06:13] hmm. [06:13] a bit long :p [06:14] heh [06:14] I didn't realise there was a length limit [06:15] meh ;) === AlexExtreme usually tries to keep it short and sweet [06:17] well, that's a start [06:17] the profile code compiled ;) [06:17] i'll test it in a minute :P [06:18] [06:18] you're supposed to write the tests *first* :p [06:25] (not that I ever do) [06:31] :P [06:32] Heh. I've never found TDD works on a budget. [06:33] I find that about 75% of my coding time is spent refactoring test cases [06:33] which is about the same amount of time I spent figuring out how I broke things [06:33] heh [06:33] ok, brb. if i don't come back, you'll know it hasn't worked :p [06:33] the net gain of course, is that the 75% now happens *before* I ship the tarball [06:34] AlexExtreme: just comment out the bits of main.c that assume pid()==1 :p [06:37] yeeep, i broke it :P [06:41] lol [06:41] somehow i'm getting an assertion failure on line 521 in string.c [06:42] how, i don't know, because i'm never calling the function that's it [06:43] *in [06:44] lol [06:44] what's the backtrace? [06:45] where does that come from? :p [06:45] core dump? [06:47] yeah [06:47] hmm [06:47] it would help if the FS was read write [06:47] hang on :p [06:52] test_cfgfile.c is annoying long [06:59] hmm [06:59] well the core dump was officially useless [07:00] init was compiled without debug symbols :P [07:02] ahhhh [07:02] i see what i did wrong :p [07:03] --disable-compiler-optimisations --disable-linker-optimisations --enable-warnings [07:03] :P [07:03] profile_get_job_status (job) << usually it helps to pass job->name to that function [07:07] let's try again ;) [07:19] Keybuk: Yeah, which is great, when you're not on a budget. ;) [07:19] Otherwise shipping the 75% is acceptable. Heh. [07:26] so it appears i'm managing to do something weird to job->cause [07:26] brb, dinner === mbiebl [n=michael@e180067250.adsl.alicedsl.de] has joined #upstart === cort [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart [07:57] woo, test passes [07:58] now to fix valgrind [08:00] easy; just a couple of "returning without freeing if -ENOMEM" bugs [08:01] it's interesting to note that i still get this assert failed if i revert all my changes [08:03] how you guys test upstart? using UML? [08:03] odd [08:03] rgl_: "make check" [08:03] how do I run upstart without being proc #1? [08:03] let's try the completely vanilla tree [08:04] rgl_: you can't at the moment, without patching the code [08:05] Keybuk, so make check tests a running upstart? [08:05] no, it tests the code [08:05] rgl_: no, it's a suite of stuff that tests the code [08:05] unit tests, basically [08:06] ah, no integration tests yet. ok. [08:07] ok, i'm getting this bug with a vanilla tree [08:07] Keybuk, want a backtrace? [08:08] sure [08:08] rgl_: define integration tests, in this case [08:09] Keybuk, http://frugalware.org/paste/1480 [08:09] I've never been clear exactly where unit and integration testing are supposed to be different [08:10] since pure unit testing supposes you can test just one function [08:10] (which you never can) [08:11] AlexExtreme: which upstart version? [08:11] it's latest bzr [08:11] 0.3.8 works fine [08:11] ah, interesting [08:12] * init/event.c (event_new): Start off with NULL args and env, to [08:12] match job (saves a few bytes). [08:12] (event_match): Watch for NULL arguments! [08:12] * init/tests/test_event.c (test_new): Check for NULL not alloc'd [08:12] heh [08:13] Keybuk, test the whole shebang as a blackbox. like, have some jobs, kill a job, see if its restarted, and stff like that. also, test the "problem" I've mention a days before: edit job, start a service that is a symlink, and see it does not work. [08:14] AlexExtreme: if statement on job.c 1372 needs "&& job->cause->info.args" added [08:15] rgl_: that's System Testing [08:16] Keybuk, isn't that the same as integration tests? [08:16] (though, its the first time I've heard of system testing hehe) [08:17] well [08:17] usually you're supposed to have [08:17] Unit Testing -> Integration Testing -> System Testing [08:17] unit supposes you can test each individual function [08:17] integration is where you join functions together, and run scenarios through it [08:18] ok, let's test that [08:18] brb [08:18] system is when you have the finished system, and apply checks to make sure it works [08:18] the Upstart test suite is something of a combination of Unit (where possible) and Integration [08:19] frequently tests are running much of the Upstart code [08:19] e.g. we have tests to set up a socket, and all of the code to listen to it, then we poke commands into it and see how the states of jobs change, and what events are emitted, etc. [08:19] ah alright :D [08:19] System Testing is when I install and reboot [08:20] and if it fails, then I don't get to my desktop, so I can't upload the tarball [08:20] hehe [08:20] though, using UML could facilitate that (but for sure you known it hehe) [08:21] I don't know UML [08:21] or do you mean User-Mode-Linux? [08:21] I use VMware for that kinda thing :p [08:21] oh yes, sorry. yes. user-mode-linux [08:21] mental note: it helps to apply the fix before testing it [08:21] yeah, I use vmware for some stuff [08:21] though mostly I just install it and see what happens [08:22] Keybuk, what line was it on (the if block to change)? [08:22] 1372 [08:23] is it bad to push incomplete code to main? :p [08:23] as long as i don't bzr pull :p [08:23] lol [08:23] you wouldn't be able to, you're diverged now, no? [08:24] true [08:24] if it works this time i'll commit it to a new branch [08:25] brb [08:27] OMG [08:27] It worked :P [08:32] bbl === cort [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart === Keybuk [n=scott@wing-commander.netsplit.com] has joined #upstart === __keybuk [n=scott@wing-commander.netsplit.com] has joined #upstart === cort [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart === cort [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart [09:23] https://code.launchpad.net/~alex-extreme2/upstart/profiles [10:02] night === mbiebl [n=michael@e180067250.adsl.alicedsl.de] has joined #upstart