_ion | Does anyone know which tool Keybuk uses for keeping the ChangeLog file updated in bzr? | 02:21 |
---|---|---|
=== theCore [n=alex@ubuntu/member/theCore] has joined #upstart | ||
=== j_ack [n=rudi@p508D8BB1.dip0.t-ipconnect.de] has joined #upstart | ||
_ion | Phew. Today was one of the few days of a year when i actually manage to get some code done despite my health issues. I wrote http://soijabanaani.net/tmp/nih_watch_delayed.diff | 04:26 |
_ion | Writing that took like ten times the time it would have taken if i could concentrate normally. | 04:26 |
_ion | Here's also a small parenthesis fix, http://soijabanaani.net/tmp/nih_hash_foreach_parenthesis.diff | 04:27 |
=== Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart | ||
=== peeps [n=peeps@cpe-70-112-25-110.austin.res.rr.com] has joined #upstart | ||
=== peeps [n=peeps@cpe-70-112-25-110.austin.res.rr.com] has left #upstart ["Leaving"] | ||
=== Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart | ||
=== j_ack [n=rudi@p508D8BB1.dip0.t-ipconnect.de] has joined #upstart | ||
=== theCore [n=alex@ubuntu/member/theCore] has joined #upstart | ||
=== AlexExtreme [n=AlexExtr@frugalware/developer/AlexExtreme] has joined #upstart | ||
=== int0x0c [n=ben@161.253.46.23] has joined #upstart | ||
=== wasabi [n=jhaltom@ubuntu/member/wasabi] has joined #upstart | ||
=== Seveas [n=seveas@ubuntu/member/seveas] has joined #upstart | ||
=== wasabi_ [n=wasabi@ubuntu/member/wasabi] has joined #upstart | ||
=== jonibo [n=jonas@213.212.2.215] has joined #upstart | ||
=== _ion [i=johan@kiviniemi.name] has joined #upstart | ||
=== popey [n=alan@ubuntu/member/popey] has joined #upstart | ||
=== j_ack_ [n=rudi@p508DA30C.dip0.t-ipconnect.de] has joined #upstart | ||
=== jonib1 [n=jonas@ua-83-227-144-18.cust.bredbandsbolaget.se] has joined #upstart | ||
=== phsdv [n=paul@dyn-83-152-239-92.ppp.tiscali.fr] has joined #upstart | ||
phsdv | int0x0c, are you trying to get upstart going on gentoo? | 11:30 |
=== juergbi [n=juerg@80-219-17-102.dclient.hispeed.ch] has joined #upstart | ||
phsdv | I just uploaded an ebuild for 0.3.5 into gentoo bugzilla (http://bugs.gentoo.org/show_bug.cgi?id=150190) | 11:45 |
=== Md [i=md@freenode/staff/md] has joined #upstart | ||
=== phsdv [n=paul@dyn-83-152-239-92.ppp.tiscali.fr] has joined #upstart | ||
=== Cubano [n=jens@0x55510128.adsl.cybercity.dk] has joined #upstart | ||
=== Keybuk [n=scott@wing-commander.netsplit.com] has joined #upstart | ||
Keybuk | so, I came up with a neat idea ... | 03:09 |
Keybuk | you know how we have emits ? | 03:09 |
Keybuk | that'd be a really nice way of defining special events | 03:09 |
Keybuk | job lists the event names with the emits stanza | 03:10 |
Keybuk | and when started, sends a message to upstart saying that it wants active notification of registrations | 03:10 |
Keybuk | upstart sees it's from a pid of a known job, that has listed emits stanzas | 03:10 |
Keybuk | so sends the job back as a reply every use of "on THAT-EVENT" | 03:10 |
Keybuk | and whenever new jobs are registered, or jobs are deleted, keeps that process up to date | 03:10 |
Keybuk | e.g. | 03:11 |
Keybuk | a job called "inetd" | 03:11 |
Keybuk | emits tcp udp | 03:11 |
Keybuk | connects to upstart | 03:11 |
Keybuk | and receives information that there are jobs with | 03:11 |
Keybuk | on tcp 80 | 03:11 |
Keybuk | on udp 53 | 03:11 |
Keybuk | etc. | 03:11 |
Keybuk | so it knows to listen on those ports, and knows to emit events with those arguments | 03:11 |
AlexExtreme | sounds good | 03:12 |
AlexExtreme | so, there's most of the work for replacing inetd done? :P | 03:14 |
Keybuk | it means you can take exotic events out of the core | 03:16 |
Keybuk | don't want inetd support? don't run upstart-ientd | 03:16 |
AlexExtreme | yes | 03:16 |
Keybuk | useful for the dbus proxy too | 03:17 |
Keybuk | on dbus com/redhat/dhcp/eth0 com.redhat.dhcp.down | 03:17 |
Keybuk | so it'd know to listen to that signal, and emit that evnet | 03:17 |
=== j_ack [n=rudi@p508D92A9.dip0.t-ipconnect.de] has joined #upstart | ||
_ion | keybuk: Ooo, really nice idea. | 04:06 |
_ion | keybuk: Any comments about the watch_delayed thing? | 04:06 |
Keybuk | I looked at the code, and it looked pretty good | 04:07 |
Keybuk | haven't had a chance to test it yet; want to get complex-event done today since we want that asap | 04:07 |
_ion | All right. | 04:07 |
Keybuk | will look at it properly this week : ) | 04:08 |
_ion | You might want to include nih_hash_foreach_parenthesis.diff immediately though, it fixes a bug. :-) | 04:09 |
Keybuk | yeah, I saw that | 04:10 |
Keybuk | thanks! | 04:10 |
Keybuk | can you paste me a changelog for that one | 04:10 |
_ion | * nih/hash.c (NIH_HASH_FOREACH, NIH_HASH_FOREACH_SAFE): Added missing parenthesis. | 04:12 |
_ion | Is that enough? :-) | 04:12 |
_ion | Duh, nih/hash.h, not .c | 04:13 |
_ion | What tool do you use to maintain the changelog and have it integrated with bzr commits, btw? | 04:13 |
_ion | A bzr plugin? | 04:13 |
Keybuk | a shell script | 04:14 |
_ion | Is it available for downloading? :-) | 04:15 |
Keybuk | http://people.ubuntu.com/~scott/software/bzr-commit | 04:15 |
_ion | Thanks | 04:15 |
Keybuk | I maintain the ChangeLog first using emacs (C-x 4 a) | 04:15 |
Keybuk | and then just use that to do the commits, with the changelog diff | 04:16 |
Keybuk | actually -- can you commit your watch delayed stuffa | 04:16 |
Keybuk | and push it to a branch of your own? | 04:16 |
Keybuk | something like | 04:18 |
_ion | Actually i did commit it to a branch of my own in the first place, but decided just to send a diff because i hadn't written changelog entries or commit messages using the format you use in your repository. I'll do that now, using that script. :-) | 04:18 |
Keybuk | bzr push sftp://ion@bazaar.launchpad.net/~ion/libnih/watch-delayed | 04:19 |
Keybuk | I think is the format | 04:19 |
Keybuk | that should automatically register it on https://code.launchpad.net/libnih | 04:19 |
=== mbiebl [n=michael@e180118213.adsl.alicedsl.de] has joined #upstart | ||
_ion | keybuk: https://code.launchpad.net/~ion/+branch/libnih/watch-delayed | 04:52 |
Keybuk | excellent | 04:54 |
Keybuk | wing-commander scott% ./parse "foo bar baz until frodo bilbo and eep" | 04:54 |
Keybuk | Operator (AND) | 04:54 |
Keybuk | Event ("eep") | 04:54 |
Keybuk | Operator (UNTIL) | 04:54 |
Keybuk | Event ("frodo", "bilbo") | 04:54 |
Keybuk | Event ("foo", "bar", "baz") | 04:54 |
Keybuk | \o/ | 04:54 |
Keybuk | now to figure out whether I've got the precedence right :p | 04:54 |
_ion | \o/ | 04:54 |
Keybuk | wing-commander scott% ./parse "foo until bar and frodo until bilbo" | 04:55 |
Keybuk | Operator (AND) | 04:55 |
Keybuk | Operator (UNTIL) | 04:55 |
Keybuk | Event ("bilbo") | 04:55 |
Keybuk | Event ("frodo") | 04:55 |
Keybuk | Operator (UNTIL) | 04:55 |
Keybuk | Event ("bar") | 04:55 |
Keybuk | Event ("foo") | 04:55 |
_ion | keybuk: You should be able to pull the nih/hash.h fix and nothing else by running bzr merge --pull -r 386 http://bazaar.launchpad.net/~ion/libnih/watch-delayed, i think. | 05:10 |
_ion | The actual delayed watch code is in revno 387. | 05:11 |
Keybuk | wing-commander scott% ./parse "set timer until (boom or kaboom)" | 05:12 |
Keybuk | Operator (UNTIL) | 05:12 |
Keybuk | Event ("set", "timer") | 05:12 |
Keybuk | Operator (OR) | 05:12 |
Keybuk | Event ("boom") | 05:12 |
Keybuk | Event ("kaboom") | 05:12 |
Keybuk | \o/ | 05:12 |
_ion | \/ | 05:13 |
AlexExtreme | :) | 05:13 |
_ion | keybuk: Have you decided a name for the complex-event-spec stanza yet? :-) | 05:13 |
Keybuk | wing-commander scott% ./parse "fhs-filesystem-mounted until fhs-filesystem-down and network-up until network-down" | 05:14 |
Keybuk | Operator (AND) | 05:14 |
Keybuk | Operator (UNTIL) | 05:14 |
Keybuk | Event ("fhs-filesystem-mounted") | 05:14 |
Keybuk | Event ("fhs-filesystem-down") | 05:14 |
Keybuk | Operator (UNTIL) | 05:14 |
Keybuk | Event ("network-up") | 05:14 |
Keybuk | Event ("network-down") | 05:14 |
Keybuk | _ion: nope | 05:14 |
Keybuk | wing-commander scott% ./parse "with apache or with thttpd" | 05:22 |
Keybuk | Operator (OR) | 05:22 |
Keybuk | Operator (WITH) | 05:22 |
Keybuk | Event ("apache") | 05:22 |
Keybuk | Operator (WITH) | 05:22 |
Keybuk | Event ("thttpd") | 05:22 |
Keybuk | yay | 05:22 |
Keybuk | even unary works | 05:22 |
_ion | Whee | 05:22 |
_ion | D'oh, i wrote "patch change events" to the changelog entry. :-) | 05:23 |
Keybuk | oops | 05:24 |
Keybuk | ok, I think the parser works | 05:26 |
Keybuk | got to make config respect parens as newline escapers, then try and recodify my ugly quick C into a stanza parser | 05:27 |
Keybuk | interesting question | 05:49 |
Keybuk | should this: | 05:49 |
Keybuk | FOO blah and (blah until blah # some comment | 05:49 |
Keybuk | or blah until blah) | 05:49 |
Keybuk | be valid | 05:49 |
Keybuk | (ie. comment inside parens | 05:49 |
_ion | I don't see why not. Someone might want to do something like this, while testing something: | 05:50 |
Keybuk | it's kinda unique in the format, since nothing else uses parens | 05:50 |
_ion | FOO something something (something # comment out the rest of the line, something something | 05:50 |
_ion | # comment out also this part, something something) | 05:51 |
_ion | new stuff) | 05:51 |
Keybuk | and I do think not being required to escape newlines inside parens is useful | 05:51 |
=== AStorm [n=astralst@host-81-190-179-124.gorzow.mm.pl] has joined #upstart | ||
AStorm | Hello. | 06:06 |
=== arachnist [i=arachnis@paludis/monkey/arachnist] has joined #upstart | ||
Keybuk | hey AStorm | 06:06 |
Keybuk | _ion: merged 386 | 06:06 |
AStorm | I've ran upstart on Gentoo, basic compatibility right now | 06:07 |
AStorm | (running large /sbin/rc, and requires a small modification of one script) | 06:07 |
Keybuk | sweet, do you have the details of what needs to be done? | 06:07 |
AStorm | I'm developing a fully event-based init system for it. | 06:07 |
Keybuk | planning to ship some example jobs in the upstart tarball directly with the next version, would be cool to have a gentoo subdir in there | 06:07 |
AStorm | And I've some questions, esp. regarding mounting | 06:07 |
Keybuk | sure | 06:07 |
AStorm | Is there something like stop for these? | 06:08 |
AStorm | Like the default plain exec is start | 06:08 |
AStorm | then stop would be ran on stopping. | 06:08 |
Keybuk | sorry, not sure I understand | 06:08 |
AStorm | Or do I have to use post-stop? | 06:08 |
AStorm | You know, I don't want to split the event in two. | 06:08 |
Keybuk | oh, I see what you mean | 06:09 |
Keybuk | upstart's jobs aren't quite analogous to init scripts | 06:09 |
AStorm | (could do this with unmount-dev script for "on stopped mount-dev") | 06:09 |
AStorm | I'd rather have it called directly in one script. | 06:09 |
Keybuk | you can do it one of two ways | 06:09 |
AStorm | Can do this in post-stop right now... | 06:09 |
Keybuk | have two jobs, mount and unmount | 06:09 |
AStorm | (or in pre-stop) | 06:09 |
Keybuk | one that mounts things, one that unmounts them | 06:09 |
AStorm | But it feels unclean. | 06:09 |
Keybuk | and have them otherwise unrelated | 06:09 |
Keybuk | or | 06:10 |
Keybuk | you can have them in one job | 06:10 |
AStorm | related related | 06:10 |
Keybuk | if you have them in one job, put the mount stuff in pre-start | 06:10 |
Keybuk | and the unmount stuff in post-stop | 06:10 |
AStorm | By the unmount one would dep "on stopped mount-dev" | 06:10 |
Keybuk | and don't have an exec or a script | 06:10 |
Keybuk | the job would appear to be "running" all the time the disk is mounted | 06:10 |
AStorm | Exactly. | 06:10 |
Keybuk | (note that there's a sliiight bug there atm) | 06:10 |
AStorm | Bug? What kind of? | 06:11 |
Keybuk | it won't ever actually stop | 06:11 |
AStorm | hmm. | 06:11 |
Keybuk | it slipped in at the last minute yesterday before I released 0.3.5 | 06:11 |
AStorm | Right, because it's no daemon and there's no SIGCHLD, right? | 06:11 |
Keybuk | I didn't have a good enough test case for it | 06:11 |
AStorm | Funny bug. So, for now, I'll split the script. | 06:11 |
Keybuk | right; because when the stop event comes in, it will only change the goal to stop -- and won't force a state change | 06:12 |
AStorm | Funny. | 06:12 |
Keybuk | this worked a few days ago | 06:12 |
AStorm | Not a problem with me, but with the users... | 06:12 |
AStorm | Now to unmount the device, they'd have to "start" the unmount | 06:13 |
AStorm | not stop the mount :-) A bit illogical. | 06:13 |
Keybuk | would you have one job per mounted disk, or one job for all of fstab ? | 06:13 |
AStorm | Rather the first one | 06:13 |
Keybuk | right | 06:13 |
AStorm | But the job would work using an argument. | 06:13 |
Keybuk | for the first one, you'd do something like: | 06:14 |
Keybuk | instance | 06:14 |
Keybuk | start on block-device-added | 06:14 |
Keybuk | stop on block-device-removed | 06:14 |
Keybuk | or something | 06:14 |
AStorm | Yes, something like that probably. | 06:14 |
Keybuk | the instance bit is important, it tells upstart that multiple copies can be running | 06:14 |
AStorm | But right now, it's /dev mounting, which is doubly funny | 06:14 |
Keybuk | (temporary fix | 06:14 |
Keybuk | rather than splitting into two jobs, just have a dummy script | 06:14 |
AStorm | Aha, nice, undocumented. | 06:14 |
Keybuk | pre-start script | 06:15 |
Keybuk | # mount stuff | 06:15 |
Keybuk | end script | 06:15 |
AStorm | Fine, very fine. | 06:15 |
Keybuk | post-stop script | 06:15 |
Keybuk | # unmount stuff | 06:15 |
Keybuk | end script | 06:15 |
AStorm | I know. the bug is just when I exec something, right? | 06:15 |
AStorm | (in full start) | 06:15 |
Keybuk | script | 06:15 |
Keybuk | while true; do sleep 1000; done | 06:15 |
Keybuk | end script | 06:15 |
_ion | sleep inf | 06:16 |
Keybuk | the script...end script will mean that there's a process running while the disk is mounted | 06:16 |
Keybuk | _ion: does that work? :p neat | 06:16 |
Keybuk | exec sleep inf | 06:16 |
Keybuk | :p | 06:16 |
_ion | It works with GNU sleep, but not with e.g. the BSD one. | 06:17 |
AStorm | Keybuk, uh, a bit evil hack, but temporarily I'll do that. | 06:17 |
Keybuk | then this week, when I fix that bug, you can drop the sleep :p | 06:17 |
AStorm | _ion, not a problem here, it's Gentoo and it's temporary. | 06:17 |
AStorm | Good, very good. | 06:18 |
Keybuk | the bug is that it won't force a state change out of running if there's no pid; because the child reaper calls job_change_goal and doesn't want a state change as a side-effect | 06:18 |
AStorm | The major thing will be forcing udev to generate events | 06:18 |
AStorm | the default rules don't do that | 06:18 |
Keybuk | this turns out to be wrong, simply because the child reaper actually does want to force a state change as a side-effect :p | 06:18 |
Keybuk | so all I need to is fix the child reaper, and remove the bogus check from job_change_goal | 06:18 |
Keybuk | need to write some test cases for it first though | 06:18 |
AStorm | Just check the state | 06:19 |
AStorm | after running some echo in pre-start | 06:19 |
AStorm | and something else in post-stop | 06:19 |
AStorm | (e.g. some file write), then check if the file was written | 06:19 |
AStorm | Without any exec inside. | 06:19 |
AStorm | I wonder if initctl stop thatservice would hang | 06:20 |
Keybuk | sorry? | 06:21 |
AStorm | The state would change properly to stopping? | 06:21 |
AStorm | Is it just that the task doesn't enter "waiting" state? | 06:21 |
AStorm | or something else totally? | 06:22 |
AStorm | Or just that it finishes too early? | 06:23 |
Keybuk | post-stop gets run in stopping | 06:24 |
Keybuk | and then it should go to waiting | 06:24 |
Keybuk | initctl hangs is probably the bug | 06:25 |
AStorm | Hmm, the test would be quite hard. | 06:27 |
AStorm | Because of the hang, you'd have to use shell job control with some timeout. | 06:27 |
AStorm | damned halting problem, eh? :P | 06:29 |
phsdv | AStorm, I have made an ebuild for 0.3.5 (in bugzilla). If you needs some help with your new scripts on gentoo, pls let me know | 06:34 |
AStorm | Well, the help would be wrt making udev send upstart events | 06:35 |
AlexExtreme | that's easy | 06:36 |
AStorm | I've overwritten my init with upstart currently, have the stupid way of compatibility (running full gentoo init) working | 06:36 |
AStorm | AlexExtreme, so then, describe it to me, I'd be grateful. | 06:36 |
Keybuk | AStorm: RUN+="initctl emit some-event" | 06:36 |
phsdv | ACTION=="add", SUBSYSTEM=="block", KERNEL=="*[!0-9] ", RUN="/usr/sbin/initctl emit block-device-added %k" | 06:37 |
AStorm | I'm not a master of init rules... | 06:37 |
AlexExtreme | damn | 06:37 |
AlexExtreme | beat me to it :) | 06:37 |
AStorm | phsdv, ok, so simple :-) | 06:37 |
AStorm | So I'll have to also do a package of udev rules - expected that. | 06:37 |
phsdv | I had them ready... wrote them a while ago | 06:37 |
Keybuk | phsdv: add "-eDEVNAME" to that | 06:37 |
phsdv | -eDEVNAME? | 06:37 |
AStorm | phsdv, could you mail them to me then? (or put somewhere I can get them) | 06:37 |
AStorm | The parameter, you know | 06:38 |
AStorm | or environment variable DEVNAME | 06:38 |
Keybuk | phsdv: put the DEVNAME environment variable in the environment of any job run by the block-device-added event | 06:38 |
_ion | -eBAR without =quux grabs the value from the current environment? Nice. | 06:38 |
AStorm | Great. It's so bad the upstart is so undocumented yet :-) | 06:38 |
phsdv | ACTION=="remove", SUBSYSTEM=="block", KERNEL=="*[!0-9] ", RUN="/usr/sbin/initctl emit block-device-removed %k" | 06:38 |
phsdv | ^ same for remove | 06:39 |
AStorm | phsdv, I know, I know. | 06:39 |
Keybuk | AStorm: heh, I do have "document it" high on the TODO list | 06:39 |
Keybuk | though remember, a lot of the features you're using today were only written in the last week <g> | 06:39 |
=== j_ack_ [n=rudi@p508DB9F4.dip0.t-ipconnect.de] has joined #upstart | ||
AStorm | Keybuk, hehe, I'll do something like that | 06:39 |
AStorm | when I finish full gentoo init script compat | 06:39 |
AStorm | which will consist of modified depscan.sh and runscript.sh | 06:39 |
AStorm | (to store the dependencies in upstart scripts) | 06:40 |
AStorm | Maybe also some mapping, like: net="network-device-eth0:network-device-eth1" | 06:40 |
AStorm | The hardest part will be deps of type "use" | 06:42 |
AStorm | The script would have to check the list of added services (simple, right :P ) | 06:42 |
AStorm | Keybuk, is it possible to parametrise the dependencies, so I don't have to generate scripts? | 06:43 |
AStorm | As in the dependency would be a parameter, some environment value? | 06:43 |
_ion | Well, you could do as Ubuntu does: keep the old compatibility layer there and gradually rewrite things from the old system to upstart. | 06:43 |
AStorm | I'm just thinking about that. | 06:44 |
AStorm | Just moving the most basic layer to upstart now | 06:44 |
AStorm | and write the compat script | 06:44 |
AStorm | Keybuk, so, is that possible? To base "dependencies" (events I want get started on) on the environment variable or a parameter? | 06:45 |
mbiebl | AStorm: What about documenting your work on the wiki? | 06:45 |
mbiebl | http://upstart.ubuntu.com/wiki/UpstartOnGentoo | 06:45 |
AStorm | I'll do that :-) | 06:45 |
AStorm | When I have something working, I'll do an ebuild and document it. | 06:45 |
mbiebl | Great, seems as many gentooers are already playing with upstart and there is much duplicated effort. | 06:46 |
AStorm | Not a lot, though. | 06:46 |
AStorm | Upstart is so nice, the amount of "work" required is low. | 06:47 |
AStorm | (except that possible conversion script - that requires a tiny bit of bash-fu) | 06:47 |
Keybuk | AStorm: I'm not sure I understand what you mean? | 06:48 |
AStorm | Keybuk, like that: | 06:48 |
AStorm | There is an event send, let's call it run-me | 06:48 |
AStorm | It is emitted with an unknown number of parameters: abc def ghi | 06:49 |
AStorm | And I want to have them converted to: on abc and on def and on ghi | 06:49 |
AStorm | Maybe a tiny extension of the syntax - explicit and? | 06:50 |
AStorm | and support for environment vars in calculation of the events/ | 06:50 |
Keybuk | so you have | 06:51 |
AStorm | E.g. I could do: initctl run-it DEPS="abc def ghi" | 06:51 |
Keybuk | "run-me abc def ghi" | 06:51 |
AStorm | and do: on $DEPS | 06:51 |
Keybuk | ? | 06:51 |
AStorm | I don't have that yet :-) | 06:51 |
Keybuk | I'm still trying to understand what you're trying to do, I'm afraid | 06:51 |
AStorm | s/initctl/initctl emit/ | 06:51 |
=== Keybuk has never seen the Gentoo init system | ||
AlexExtreme | it's *very* complicated :) | 06:52 |
AStorm | Keybuk, it's a simple "need" based system | 06:52 |
AStorm | AlexExtreme, not really | 06:52 |
AStorm | With some "after and before" | 06:52 |
Keybuk | so when a job starts, it causes the jobs it needs to also be started? | 06:52 |
AlexExtreme | it seemed that way to me :P | 06:52 |
AStorm | Keybuk, exactly. | 06:52 |
Keybuk | or is it the kind where a job is not started until everything it needs has been started by something else? | 06:52 |
AStorm | Like that old "depend" trick | 06:52 |
AStorm | Which was obsoleted some time ago | 06:53 |
AStorm | Keybuk, the second one rather | 06:53 |
Keybuk | in upstart, if "FOO" needs "BAR" then in FOO's job file, you would write: | 06:53 |
Keybuk | start on started FOO | 06:53 |
Keybuk | stop on stopping FOO | 06:53 |
AStorm | Exactly. | 06:53 |
Keybuk | err | 06:53 |
Keybuk | s/FOO/BAR/ in that :p | 06:53 |
AStorm | And I'd add in the main one: start on gentoo | 06:53 |
AStorm | and stop on gentoo | 06:54 |
AStorm | that one would emit proper events to run things | 06:54 |
Keybuk | in the main one? | 06:54 |
AStorm | Something like that, right. | 06:55 |
Keybuk | main what? | 06:55 |
AStorm | A conversion of Gentoo init to rcS, so it seems. | 06:55 |
AStorm | It's just that the script "gentoo" would call the wrapper for gentoo-style init multiple times | 06:55 |
Keybuk | maybe I need to rewind here | 06:55 |
Keybuk | are you wanting to know how to rewrite current init scripts into upstart native jobs ... | 06:55 |
AStorm | and this wrapper would get the deps right (precalculated by script) | 06:56 |
Keybuk | ... or are you trying to find out how to write a generic job that can start any gentoo init script ? | 06:56 |
AStorm | Keybuk, the last one | 06:56 |
Keybuk | aha! | 06:56 |
Keybuk | right, basis of my confusion here then :p; | 06:56 |
AStorm | This would simulate gentoo runlevels. | 06:56 |
AStorm | and the smaller script would just launch things | 06:57 |
Keybuk | well, at the most basic level, you need a job that handles the simple case of starting, running and stopping one job | 06:57 |
AStorm | Exactly, but with parametrised deps | 06:57 |
Keybuk | ideally, that would need to spawn the job in the pre-start script, and then kill it again in the post-start script | 06:57 |
AStorm | But then, I'd need a wildcard | 06:57 |
Keybuk | and somehow wedge in the running state while the job is actually running | 06:57 |
AStorm | Yes. | 06:58 |
Keybuk | first you need to write the job, without any deps | 06:58 |
Keybuk | you could do it all in "script" in fact | 06:58 |
Keybuk | script | 06:58 |
Keybuk | /etc/init.d/$JOB start | 06:58 |
AStorm | Exactly | 06:58 |
AStorm | That's what I want... | 06:58 |
Keybuk | while [ -f /var/run/$JOB.pid ] ; do sleep 1; done | 06:58 |
AStorm | but for deps I'd need to match on the JOB variable | 06:58 |
Keybuk | /etc/init.d/$JOB stop | 06:58 |
Keybuk | end script | 06:58 |
AStorm | No pidfile support | 06:58 |
Keybuk | though that's not quite right, since stopping the upstart job would not stop the gentoo one | 06:58 |
Keybuk | what I might do there is | 06:59 |
AStorm | Gentoo is using the pids itself in the scripts | 06:59 |
Keybuk | post-start script | 06:59 |
Keybuk | /etc/init.d/$JOB start | 06:59 |
Keybuk | end script | 06:59 |
Keybuk | script | 06:59 |
AStorm | Just call /etc/init.d/$JOB stop | 06:59 |
AStorm | Yes, that's it. | 06:59 |
Keybuk | while /etc/init.d/$JOB is-running; do sleep 1; done | 06:59 |
Keybuk | end script | 06:59 |
Keybuk | pre-stop script | 06:59 |
Keybuk | /etc/init.d/$JOB stop | 06:59 |
Keybuk | end script | 06:59 |
AStorm | "is-running" is impossible yet. Just sleep instead :P | 06:59 |
Keybuk | right, but how do you know if someone stops the job when you weren't looking? :p | 06:59 |
Keybuk | if you don't care, then omit the "script ... end script" bit | 07:00 |
AStorm | Well... | 07:00 |
Keybuk | (and replace with exec sleep inf until I fix this bug) | 07:00 |
AStorm | Exactly, don't care. | 07:00 |
Keybuk | ok | 07:00 |
AStorm | Stupidity is not rewarded :P | 07:00 |
Keybuk | so this gives you a job that will start and stop any gentoo job when it, itself, is started and stopped | 07:00 |
AStorm | And init scripts are disallowed to call stop on others explicitly | 07:00 |
AStorm | (Gentoo policy) | 07:00 |
Keybuk | of course, you need to mark this "instance" because you want multiple copies running | 07:00 |
AStorm | Yes. | 07:00 |
AStorm | But I need a match on $JOB | 07:00 |
Keybuk | now, you'll want an event to start up an instance for a given job | 07:01 |
Keybuk | and another event to stop an instance for the same job | 07:01 |
Keybuk | easiest way to define that | 07:01 |
AStorm | to start its deps earlier | 07:01 |
Keybuk | initctl emit gentoo-start -eGENTOO_JOB=NAMEOFJOB | 07:01 |
Keybuk | initctl emit gentoo-stop -eGENTOO_JOB=NAMEOFJOB | 07:01 |
AStorm | Yes. | 07:01 |
Keybuk | so stick in the gentoo job file | 07:01 |
Keybuk | start on gentoo-start | 07:01 |
Keybuk | stop on gentoo-stop | 07:01 |
AStorm | But then, the deps are to be given as the parameters still | 07:01 |
AStorm | (because of the need system) | 07:01 |
Keybuk | and use $GENTOO_JOB throughout | 07:01 |
AStorm | or the single script won't work | 07:01 |
Keybuk | (getting to dependencies) | 07:01 |
AStorm | Can I do a match like: | 07:02 |
AStorm | on gentoo-start GENTOO_JOB=xyz * | 07:02 |
Keybuk | no | 07:02 |
AStorm | or would the DEPS variable be ignored? | 07:02 |
AStorm | (if I don't match on it) | 07:02 |
Keybuk | question | 07:02 |
Keybuk | how would you like deps to be handled? | 07:02 |
Keybuk | if you start FOO, should it cause its deps to be started? | 07:03 |
AStorm | Yes. | 07:03 |
Keybuk | right | 07:03 |
AStorm | and then foo itself. | 07:03 |
Keybuk | so now we improve the "gentoo-start" event | 07:03 |
AStorm | Yep. | 07:03 |
Keybuk | initctl emit gentoo-stop -eGENTOO_JOB=NAMEOFJOB -eGENTOO_DEPS="dep1 dep2 dep3 dep4" | 07:03 |
Keybuk | uh | 07:03 |
Keybuk | s/-stop/-start/ :p | 07:03 |
AStorm | Not a problem. | 07:03 |
Keybuk | now that instance, when it gets started, has $GENTOO_JOB which is the job we actually want to run | 07:03 |
Keybuk | (used in post-start and pre-stop) | 07:04 |
AStorm | I'd love to avoid parsing the GENTOO_DEPS though. there's no way yet, right? | 07:04 |
AStorm | (like just putting on started $GENTOO_DEPS) | 07:04 |
AStorm | Or rather: | 07:04 |
AStorm | when $GENTOO_DEPS | 07:04 |
Keybuk | and that instance also has $GENTOO_DEPS | 07:04 |
Keybuk | so the simplest way is to add | 07:04 |
Keybuk | pre-start script | 07:04 |
AStorm | which would expand to when dep1 and when dep2 and when dep3 | 07:04 |
Keybuk | for DEP in $GENTOO_DEPS; initctl emit gentoo-start $DEP; done | 07:04 |
Keybuk | end script | 07:04 |
Keybuk | that wouldn't do what you want | 07:05 |
Keybuk | that would emulate the second kind of system | 07:05 |
AStorm | It would do it too :-) | 07:05 |
AStorm | Ah, right. | 07:05 |
AStorm | the need would add when | 07:05 |
AStorm | the use would add on | 07:05 |
AStorm | :-) | 07:05 |
AStorm | that's the catch | 07:05 |
AStorm | Or even better. | 07:05 |
AStorm | use would still add when | 07:05 |
AStorm | after would add on | 07:05 |
Keybuk | err? | 07:05 |
AStorm | before would work like after, but backwards | 07:06 |
AStorm | Gentoo has 4 kinds of deps: | 07:06 |
Keybuk | nope, completely lost me | 07:06 |
AStorm | need, use, before and after | 07:06 |
AStorm | need means a hard dependency | 07:06 |
Keybuk | need implies that if you try and start $JOB, then its dependencies come up first | 07:06 |
AStorm | so we should get restarted when the dependency is | 07:06 |
Keybuk | ? | 07:06 |
AStorm | Yes | 07:06 |
AStorm | But also when you restart that dependency, the package itself is restarted too. Like when | 07:07 |
AStorm | use is like when, but optional - that's only a problem for dependency precalculator, to see if the thing is added to the runlevel and add the dep then | 07:07 |
Keybuk | ok | 07:07 |
AStorm | after and before are for ordering, doable using on. | 07:08 |
Keybuk | random thought; I wouldn't pass $UPSTART_DEPS as part of the evnet | 07:08 |
Keybuk | s/UPSTART/GENTOO/ | 07:08 |
Keybuk | in the pre-start script, I'd parse the gentoo init script to get them | 07:08 |
AStorm | Hmm... | 07:08 |
Keybuk | that way you don't need to duplicate code everywhere | 07:08 |
AStorm | And add the aliases there too? | 07:08 |
Keybuk | right | 07:08 |
AStorm | Would be very fat. | 07:08 |
AStorm | Bad idea. | 07:08 |
AStorm | I can precalculate them. | 07:09 |
Keybuk | yeah, but you have a single job then which handles the entire case of starting and stopping a gentoo init script | 07:09 |
Keybuk | and just needs the name | 07:09 |
Keybuk | rather than trying to duplicate the code everywhere | 07:09 |
AStorm | Yes. | 07:09 |
Keybuk | you'd need the "extract list of deps" code in several places, otherwise | 07:09 |
AStorm | But parsing is slow. | 07:09 |
AStorm | I want to avoid this slowness by parsing once. | 07:09 |
AStorm | Just once - in adding the deps :-) | 07:09 |
AStorm | E.g. in gentoo depscan.sh | 07:10 |
AStorm | The deps would be perfectly calculated using that. | 07:10 |
AStorm | and then just set in the script, like a simple list | 07:10 |
AStorm | WHEN_DEPS="abc def ghi" ON_DEPS="xyz zy" | 07:10 |
Keybuk | right | 07:11 |
Keybuk | but then the job doesn't need to care about its deps, surely? | 07:11 |
Keybuk | if their parsed elsewhere, they can be handled elsewhere as well | 07:12 |
AStorm | Ugh... I'd prefer to have upstart order them | 07:12 |
AStorm | parallelise them | 07:12 |
AStorm | and not do that myself :-) | 07:12 |
Keybuk | right | 07:12 |
Keybuk | but then you end up with the situation where the job doesn't just need to know *its* deps | 07:12 |
Keybuk | it needs the list of deps for every one if its deps | 07:13 |
AStorm | Yep | 07:13 |
Keybuk | and their deps | 07:13 |
AStorm | I could generate multiple job files, well | 07:13 |
AStorm | with the deps pregenerated | 07:13 |
AStorm | but the only catch is that I'd have to regenerate some if a "use" dependency changed. Not that bad. | 07:13 |
AStorm | More clutter and puts the init code generator in the depscan.sh | 07:14 |
Keybuk | I can see quite easily how to convert a Gentoo init script into an Upstart job | 07:14 |
AStorm | Yes, it's damn simple most of the time | 07:14 |
_ion | What do you need the gentoo-start job for? Wouldn't it be enough just to start the existing rc script? | 07:14 |
Keybuk | but how to make a generic job that emulates the behaviour, without that job parsing the Gentoo init script, not sure | 07:14 |
AStorm | Just the script | 07:14 |
AStorm | _ion, for the deps | 07:14 |
AStorm | gentoo init script uses #!/sbin/runscript.sh | 07:15 |
Keybuk | the existing rc script handles all the deps :p | 07:15 |
_ion | I mean, the existing thing already handles the dependencies. | 07:15 |
Keybuk | it's not mad to try and replace it though | 07:15 |
AStorm | Yes. | 07:15 |
AStorm | But it's evil. | 07:15 |
Keybuk | e.g. we could have a sysv layer that iterated /etc/rc.d itself, etc. | 07:15 |
AStorm | It's damned slow | 07:15 |
AStorm | Keybuk, indeed. But then, I just need to mutate rc-update :P | 07:15 |
AStorm | And add some additional event parsing, like for reload and others. | 07:16 |
AStorm | So I'll just add a converter. | 07:16 |
AStorm | Hope it turns out well... would have to detect start-stop-daemon pidfile handling, not that bad. | 07:16 |
Keybuk | sounds like a fun project <g> | 07:16 |
AStorm | (of course, it wouldn't detect some broken scripts :P ) | 07:16 |
_ion | Wouldn't that be a motivator for people to migrate their scripts to upstart jobs? :-) Then one nice day you notice that nobody uses the compatibility layer anymore. | 07:16 |
AStorm | _ion, yep :-) | 07:17 |
_ion | The slowness, that is. | 07:17 |
AStorm | The broken scripts more so | 07:17 |
AStorm | like mysql one, it does a lot of weird things | 07:17 |
AStorm | Like checking the config on running, which should rather be done by hand | 07:17 |
AStorm | _ion, I already have a crappy compat layer :P | 07:18 |
AStorm | Want it to become a bit better, so that I can sell upstart performance | 07:18 |
AStorm | (even on Gentoo init scripts converted to upstart scripts) | 07:18 |
AStorm | along with daemon autorestarting for some cases (where I can easily detect that a daemon is launched) | 07:19 |
Keybuk | http://people.ubuntu.com/~scott/cant-stop-execless-job.patch | 07:19 |
Keybuk | ^ that fixes the bug that means you need "exec sleep inf" | 07:19 |
AStorm | Keybuk, thanks :-) | 07:19 |
AStorm | Applying now :-) | 07:20 |
AStorm | The only minus is that I have to muck with that stupid configure script | 07:20 |
AStorm | that tries to install docs into PREFIX, and some other things too | 07:20 |
AStorm | instead of using EPREFIX | 07:20 |
AStorm | Blah, the other way around | 07:21 |
AStorm | Ugh, my badness, checked what I passed in the logs :P | 07:22 |
Keybuk | it does? | 07:22 |
AStorm | No, it doesn't. A brain fart. | 07:23 |
Keybuk | :p | 07:23 |
AStorm | Hmm, the ChangeLog conflicted :P | 07:24 |
AStorm | (expected - the patch is probably against bzr) | 07:24 |
Keybuk | yes | 07:24 |
AStorm | Ok, now on to more hacking - writing that basic layer | 07:25 |
Keybuk | hmm | 07:26 |
Keybuk | initctl stop doesn't hang for me here | 07:26 |
AStorm | and then to some converter | 07:26 |
AStorm | Keybuk, it shouldn't | 07:26 |
AStorm | I just supposed it would. I mean the job should be set as waiting | 07:26 |
AStorm | but then stopped only on explicit stop | 07:26 |
AStorm | Or even maybe... just hold in the running state. | 07:27 |
AStorm | Even better. | 07:27 |
Keybuk | you can do that | 07:27 |
AStorm | Will it be running? | 07:27 |
AStorm | (until stopped, that is) | 07:27 |
Keybuk | you've got the source in front of you? | 07:27 |
Keybuk | look at doc/states.png | 07:27 |
Keybuk | that's the state transition diagram | 07:28 |
Keybuk | notice that pre-stop blister at the top right | 07:28 |
Keybuk | pre-stop is special | 07:28 |
Keybuk | when you run "stop JOB" or when an event that the job has in "stop on EVENT" is emitted ... | 07:28 |
AStorm | Ok, nice :-) | 07:28 |
Keybuk | ... the job goes into pre-stop instead of stopping | 07:28 |
AStorm | Good. | 07:28 |
Keybuk | the pre-stop script can therefore decide to delay the stop | 07:28 |
AStorm | That's what I expected. | 07:28 |
Keybuk | or even revert it altogether | 07:28 |
AStorm | (it won't delay) | 07:29 |
Keybuk | in "pre-stop script", if the job cannot be stopped, just run "start" :) | 07:29 |
AStorm | The task is set to stopped after post-stop, right? | 07:29 |
Keybuk | there's no "stopped" state | 07:29 |
Keybuk | if you mean when does the stopped event get emitted, that is after post-stop, yes | 07:29 |
AStorm | Yes. | 07:29 |
AStorm | Good. | 07:29 |
AStorm | the pre-start is ran when? | 07:30 |
AStorm | just before the start itself, right? | 07:31 |
AStorm | with the starting event emitted, or no? (vetoable?) | 07:31 |
AStorm | and the started is after post-start? | 07:31 |
AStorm | I'm reading the graph right? | 07:31 |
Keybuk | starting is emitted | 07:32 |
Keybuk | then pre-start is run | 07:32 |
Keybuk | then the "exec"/"script" process (if any) is spawned | 07:32 |
Keybuk | then post-start is run | 07:32 |
Keybuk | then started is emitted | 07:32 |
Keybuk | -- | 07:32 |
Keybuk | pre-stop is run | 07:32 |
Keybuk | then stopping is emitted | 07:32 |
Keybuk | then the "exec"/"script" process (if any) is killed | 07:32 |
Keybuk | then post-stop is run | 07:33 |
Keybuk | then stopped is emitted | 07:33 |
AStorm | What about when pre-start vetoes? | 07:33 |
Keybuk | -- | 07:33 |
AStorm | Is the stopping emitted? | 07:33 |
Keybuk | if pre-start runs "stop", then you get stopping and stopped emitted | 07:33 |
AStorm | Hmm... | 07:33 |
Keybuk | (red line out of pre-start) | 07:33 |
AStorm | Bad for my health :P | 07:33 |
AStorm | I'd just like to veto a start | 07:33 |
AStorm | Go back to waiting then deleted maybe... | 07:33 |
AStorm | Some way. | 07:34 |
AStorm | So that whichever got started due to starting event, is there | 07:34 |
Keybuk | tbh, I can't remember why starting/pre-start are that way round, but pre-stop/stopping are the other way around | 07:34 |
AStorm | (even if it's listening on stopped) | 07:34 |
Keybuk | you can do that in an odd way | 07:35 |
AStorm | Ah right. | 07:35 |
AStorm | a fail event | 07:35 |
Keybuk | if you have something that does "start on starting" | 07:35 |
AStorm | This won't call the stopping, right? | 07:35 |
Keybuk | then it can look at $1, and call "stop $1" :) | 07:35 |
AStorm | Hmm. | 07:35 |
Keybuk | (the theory is that pre-start's "opposite job" is post-stop) | 07:36 |
AStorm | Because those Gentoo scripts are pesky and I want to emulate the whole behaviour | 07:36 |
Keybuk | so if you run pre-start, you always need to run post-stop | 07:36 |
Keybuk | and because post-stop is run, you'd get a stopped event | 07:36 |
Keybuk | so you need some kind of starting event first | 07:36 |
AStorm | the brokenness is that the deps aren't stopped when the task fails to start | 07:36 |
AStorm | (e.g. due to checkconfig) | 07:36 |
Keybuk | and since you have a starting event, you also need a stopping event, since some things might run between those two things | 07:37 |
AStorm | And I'd have to do that in the script itself then :P | 07:37 |
Keybuk | that's possible in upstart | 07:37 |
AStorm | And can't dep on started :/ | 07:37 |
Keybuk | gentoo-start/failed | 07:37 |
AStorm | Hmm. | 07:37 |
AStorm | I know. | 07:37 |
Keybuk | that event will be emitted if the job it tried to start failed to start | 07:37 |
AStorm | They'd have to depend on both the usual and the failed :P | 07:37 |
AStorm | Brokenness emulated bug for bug. | 07:37 |
AStorm | The slash is required, or can I write on started gentoo-start failed? | 07:38 |
AStorm | or even * there? | 07:38 |
Keybuk | slash is required | 07:38 |
Keybuk | since it's a different event | 07:38 |
AStorm | Ah, ok. | 07:38 |
AStorm | Not a problem. | 07:38 |
Keybuk | you could also do something like; exit 1 from pre-start to fail the job | 07:39 |
Keybuk | then you get a "gentoo-job stopping failed pre-start" event :p | 07:39 |
AStorm | But that wouldn't launch the deps. | 07:39 |
AStorm | I want to emulate bug for bug :P | 07:39 |
AStorm | I think I'll go with the "multiple files" approach. | 07:40 |
AStorm | code duplication all right, but will look more like handwritten code | 07:41 |
AStorm | the runscript would still have to be modified anyway, to disable its own dep resolution | 07:41 |
Keybuk | right | 07:41 |
Keybuk | dinner | 07:41 |
Keybuk | bbl | 07:42 |
Keybuk | enjoy | 07:42 |
AStorm | Or is there a way to bypass #! line? | 07:42 |
Keybuk | sure sh -escript | 07:42 |
AStorm | Great. | 07:42 |
AStorm | Hmm, even the "when" would be too far | 07:45 |
AStorm | Just on | 07:45 |
AStorm | stop on stopping ourdep | 07:46 |
AStorm | Because that's broken in Gentoo init scripts too :P | 07:46 |
AStorm | Blah, even better | 07:48 |
AStorm | I just need to source the given init script | 07:48 |
AStorm | then call its "start" function | 07:48 |
AStorm | the more problematic would be reload which some scripts have | 07:48 |
AStorm | Which doesn't necessarily just restart the app. | 07:48 |
AStorm | Though that could be just an another handler, e.g. on some parameter | 07:49 |
AStorm | So you could do: initctl emit xyzzy reload | 07:49 |
AStorm | or initctl emit xyzzy stop | 07:49 |
AStorm | Or better, initctl stop xyzzy | 07:49 |
AStorm | Simple then. | 07:50 |
AStorm | Just read OPTS variable. | 07:50 |
AStorm | (gets sourced in) | 07:51 |
AStorm | the reload is the default one | 07:51 |
AStorm | If not present, it's just start/stop, will have to emulate that somehow. | 07:51 |
AStorm | Probably by defining our own bash function, then sourcing. This will override our own definition. | 07:59 |
AStorm | Wouldn't it be nice to have the reload event separated from restarting, generally? | 08:02 |
AStorm | E.g. special events "reloading xyzzy" "reloaded xyzzy" | 08:03 |
AStorm | But then... the reload xyz would just emit these simply and call pre-reload | 08:04 |
AStorm | reload | 08:04 |
AStorm | and post-reload | 08:04 |
AStorm | Actually, just launch a reload event with reloading and reloaded. No need for special syntax :> | 08:04 |
_ion | That could be useful. Let's ask Keybuk's thoughts about it when he returns. | 08:05 |
AStorm | Of course, the states would only be emitted if the event had reload in it. | 08:10 |
AStorm | and add the initctl function reload | 08:12 |
AStorm | it'd fail if the event wouldn't support it | 08:12 |
AStorm | s/wouldn't/didn't/ | 08:13 |
AStorm | could just fall back to stop/start | 08:15 |
AStorm | or just start if not running | 08:16 |
AStorm | Temporarily, I'll just create more events | 08:30 |
AStorm | Actually, I'll use a parameter. | 08:31 |
AStorm | These become just $1, $2 etc? | 08:31 |
AStorm | I'm wondering... how to avoid checking filesystems from the same drive in parallel | 08:56 |
AStorm | Hmm. | 08:56 |
AStorm | Maybe just something simple... I'd do away with the fstab anyway - it'd be parsed. | 08:57 |
AStorm | Well, the simplest would be to just sort based on the drive ID, using standard Unix device names... but that'd break with LVM and some Udev manglings | 09:00 |
AStorm | LVM can be worked around by parsing lvs | 09:01 |
AStorm | But don't know about udev... | 09:01 |
_ion | The Ubuntu people might have a solution for that problem. They've surely had to think about it, as they're going to implement that for the next release. | 09:03 |
_ion | Better ask Keybuk. | 09:04 |
AStorm | Hmm... or maybe not :P | 09:04 |
AStorm | Maybe they just punted at the problem - the scanning will just get slower | 09:04 |
AlexExtreme | Keybuk said he would release an upstart-based init sequence for ubuntu today or tomorrow, we should wait to see what's been done there | 09:04 |
AStorm | Great, just great. I shall see. | 09:05 |
=== Md [i=md@freenode/staff/md] has joined #upstart | ||
AStorm | Uh, yes, md would be problematic too (no, not you) | 09:05 |
AlexExtreme | :P | 09:05 |
AStorm | RAID and stuff - you don't know which is on which physical disc. | 09:05 |
AStorm | Would need physical FS data. | 09:06 |
AStorm | Hmm... there is an option... | 09:06 |
AStorm | parsing /proc/diskstats | 09:06 |
AStorm | Just do a simple read on each of the partitions | 09:07 |
AStorm | and see which disk's stats got upped | 09:07 |
AStorm | But that'd have to be done in single mode. | 09:07 |
AStorm | If one could get a hardware Udev id... | 09:09 |
AStorm | But then, that doesn't tell us anything about LVM or RAID. Though these can be worked around. | 09:09 |
arachnist | wasn't upstart supposed to be crossplatform? i'm quite sure that /proc/diskstats is nonexistant on bsd's, even with linprocfs mounted on /proc | 09:10 |
AlexExtreme | well | 09:10 |
AlexExtreme | this would be in the job files | 09:10 |
AlexExtreme | which are distro specific | 09:11 |
AStorm | :> | 09:11 |
arachnist | oh, ok | 09:11 |
AStorm | Ok. | 09:12 |
AStorm | udevinfo returns the hardware ID. | 09:12 |
AStorm | One problem less. Now I'll check the LVM. | 09:12 |
AStorm | Hmm, udevinfo is useless against LVM or RAID. | 09:17 |
AStorm | But these fortunately have their own tools. RAID has mdstatus | 09:17 |
AStorm | LVM has lvs | 09:17 |
=== theCore [n=alex@ubuntu/member/theCore] has joined #upstart | ||
AStorm | The parsing would be done by a special util, so as not to slow down the startup. Will write such a script now. | 09:18 |
AStorm | lvs+pvs for LVM (converting to physical device), udevinfo for physical volumes | 09:21 |
AStorm | Don't remember md, so it'll have to wait. | 09:21 |
Md | I think you are looking for /lib/udev/vol_id | 09:22 |
_ion | Ubuntu added /lib/udev/watershed to the udev packaging recently, it should be helpful when multiple fscks are supposed to be run. | 09:23 |
_ion | (i think) | 09:23 |
AStorm | Md, that's one thing. | 09:23 |
AStorm | No, udevinfo will be enough. | 09:24 |
AStorm | vol_id requires the device path, so it's useless. | 09:24 |
AlexExtreme | _ion, what does that do? | 09:24 |
AStorm | Knowing the device path means I know everything. | 09:24 |
AStorm | For knowing the LVM volumes, one just needs to run vgscan - and that's needed anyway | 09:25 |
AStorm | vgscan, then parse lvs and pvs info | 09:26 |
AStorm | then we get the device name. | 09:26 |
AStorm | Which can be probed using udevinfo --name=device --query=env | 09:26 |
AStorm | to get the unique hardware id | 09:26 |
_ion | alexextreme: If you run /lib/udev/watershed sleep 2 twice, the other one won't be started until the first one has finished. | 09:27 |
AlexExtreme | ah | 09:27 |
AStorm | Even better :> | 09:27 |
AStorm | One can just do some ls on sysfs | 09:28 |
AStorm | to get where the device mappings are stored | 09:28 |
AStorm | I'll see the libsysfs | 09:28 |
AStorm | Yes, there is a tool in sysfsutils | 09:30 |
AStorm | systool | 09:30 |
AStorm | But why depend on an external tool, when few ls or finds will suffice? | 09:32 |
AStorm | *a few | 09:32 |
AStorm | The basic partitions are just subdirs of the drive subdirectory | 09:33 |
AStorm | the device mappings are on their own, but they have the parition(s) they're contained in symlinked in slaves subdir | 09:34 |
AStorm | Also, the partitions/discs have the symlink to the mappings in holders | 09:35 |
AStorm | subdirectory | 09:35 |
AStorm | Simple enough to write a script to detect that in realtime. | 09:36 |
AStorm | Only swap partitions will have to be ignored... | 09:38 |
AStorm | (/proc/swaps) | 09:39 |
AStorm | Bah, can't use /proc/swaps. | 09:39 |
AStorm | The entry won't be there yet, the swap isn't enabled. | 09:39 |
_ion | Yay, i booted my computer using upstart 0.3.5 + my watch_delayed patch. It works. | 09:40 |
AStorm | The simplest would be to create fsck.swap, which does nothing. | 09:40 |
AStorm | How does one detect that a partition is swap in Linux? :> | 09:43 |
AStorm | w/o trying to mount it | 09:43 |
AStorm | Ah, right. | 09:45 |
AStorm | mount -f -v | 09:45 |
AStorm | Blah, that does print unknown only | 09:46 |
AStorm | Any ideas? | 09:46 |
=== arachnis1 [i=arachnis@088156186027.who.vectranet.pl] has joined #upstart | ||
=== arachnis1 is now known as arachnist | ||
phsdv | you do not want to look in /etc/fstab? I mean there could be swap partitions that I do not want to use | 10:00 |
AlexExtreme | hmm | 10:01 |
AlexExtreme | just installed herd 2 in vmware from an iso i downloaded a while back | 10:01 |
AlexExtreme | "only" 409 updates :p | 10:01 |
AlexExtreme | night | 10:03 |
=== arachnis1 [i=arachnis@088156186027.who.vectranet.pl] has joined #upstart | ||
phsdv | night | 10:04 |
=== phsdv [n=paul@dyn-83-152-239-92.ppp.tiscali.fr] has left #upstart ["Time] | ||
=== AstralSt [n=astralst@host-81-190-179-124.gorzow.mm.pl] has joined #upstart | ||
=== AstralSt is now known as ASotrm | ||
=== ASotrm is now known as AstralSt | ||
=== AstralSt is now known as AStorm | ||
AStorm | Blah, it's just a syscall, that swapon. | 10:21 |
AStorm | Heh, the first page of swap contains a magic ID | 10:35 |
AStorm | SWAP SPACE for old swap | 10:36 |
AStorm | SWAPSPACE2 for newer one | 10:36 |
AStorm | SWAP-SPACE for old | 10:36 |
AStorm | old is unsupported in 2.6 AFAIK anyway, so we don't have to bother. | 10:36 |
AStorm | The only thing I have to know is current page size. | 10:36 |
AStorm | Now, the idea is - can I get the pagesize w/o launching any C code? :P | 10:39 |
AStorm | (that and some head+tail would be enough for basic detection) | 10:39 |
=== AStorm [n=astralst@host-81-190-179-124.gorzow.mm.pl] has joined #upstart | ||
AStorm | In case of problems, I'll just punt and check the largest pagesize | 10:51 |
AStorm | Ah, it should be in the libc headers. | 10:54 |
AStorm | Ok, it's in Linux :P | 11:00 |
AStorm | The largest number of bytes is 1 << 22 | 11:00 |
AStorm | That's some kind of sparc64 | 11:00 |
AStorm | Usually it's 1 << 12 or 4096 | 11:00 |
AStorm | 1 << 22 is... 4MB! | 11:01 |
AStorm | Now that's some page :> | 11:01 |
AStorm | I'd like to avoid grepping 4 MB of the swapfile, but oh well :P | 11:04 |
AStorm | head -n 4m | grep -U SWAPSPACE2 is ok... but.. | 11:16 |
AStorm | I think that trying to swapon would be faster than that... | 11:17 |
AStorm | though the simple check would be faster if I could somehow get the page size | 11:17 |
AStorm | or write a tiny C prog "isswap" | 11:17 |
_ion | Keybuk's dinner has taken a while. :-) | 11:48 |
AStorm | Right. | 11:51 |
AStorm | And I've finished that swap detector | 11:51 |
AStorm | as a bonus, it detects old v1 swap space as non-swap | 11:51 |
AStorm | so will bork :-) | 11:51 |
AStorm | A special return code of 2 | 11:51 |
AStorm | 1 if not swap space | 11:51 |
AStorm | 0 if swap space v2 | 11:51 |
AStorm | 254 for file open error | 11:52 |
AStorm | 255 for argument error | 11:52 |
AStorm | No usage (quite obvious - give it a device name) | 11:52 |
AStorm | Uses mmap for extra speed :P | 11:53 |
_ion | In case anyone's interested, this is the upstart patch i've been using for a while, it seems to do the right thing. http://soijabanaani.net/tmp/upstart_watch_delayed.diff | 11:53 |
_ion | It compiles with the libnih from https://code.launchpad.net/~ion/+branch/libnih/watch-delayed | 11:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!