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