[02:21] <_ion> Does anyone know which tool Keybuk uses for keeping the ChangeLog file updated in bzr?
[04:26] <_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:27] <_ion> Here's also a small parenthesis fix, http://soijabanaani.net/tmp/nih_hash_foreach_parenthesis.diff
[11:30] <phsdv> int0x0c, are you trying to get upstart going on gentoo?
[11:45] <phsdv> I just uploaded an ebuild for 0.3.5 into gentoo bugzilla (http://bugs.gentoo.org/show_bug.cgi?id=150190) 
[03:09] <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:10] <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:11] <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:12] <AlexExtreme> sounds good
[03:14] <AlexExtreme> so, there's most of the work for replacing inetd done? :P
[03:16] <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:17] <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
[04:06] <_ion> keybuk: Ooo, really nice idea.
[04:06] <_ion> keybuk: Any comments about the watch_delayed thing?
[04:07] <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:08] <Keybuk> will look at it properly this week : )
[04:09] <_ion> You might want to include nih_hash_foreach_parenthesis.diff immediately though, it fixes a bug. :-)
[04:10] <Keybuk> yeah, I saw that
[04:10] <Keybuk> thanks!
[04:10] <Keybuk> can you paste me a changelog for that one
[04:12] <_ion>         * nih/hash.c (NIH_HASH_FOREACH, NIH_HASH_FOREACH_SAFE): Added missing parenthesis.
[04:12] <_ion> Is that enough? :-)
[04:13] <_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:14] <Keybuk> a shell script
[04:15] <_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:16] <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:18] <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:19] <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:52] <_ion> keybuk: https://code.launchpad.net/~ion/+branch/libnih/watch-delayed
[04:54] <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:55] <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")
[05:10] <_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:11] <_ion> The actual delayed watch code is in revno 387.
[05:12] <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:13] <_ion> \/
[05:13] <AlexExtreme> :)
[05:13] <_ion> keybuk: Have you decided a name for the complex-event-spec stanza yet? :-)
[05:14] <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:22] <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:23] <_ion> D'oh, i wrote "patch change events" to the changelog entry. :-)
[05:24] <Keybuk> oops
[05:26] <Keybuk> ok, I think the parser works
[05:27] <Keybuk> got to make config respect parens as newline escapers, then try and recodify my ugly quick C into a stanza parser
[05:49] <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:50] <_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:51] <_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
[06:06] <AStorm> Hello.
[06:06] <Keybuk> hey AStorm
[06:06] <Keybuk> _ion: merged 386
[06:07] <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:08] <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:09] <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:10] <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:11] <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:12] <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:13] <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:14] <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:15] <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:16] <_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:17] <_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:18] <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:19] <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:20] <AStorm> I wonder if initctl stop thatservice would hang
[06:21] <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:22] <AStorm> or something else totally?
[06:23] <AStorm> Or just that it finishes too early?
[06:24] <Keybuk> post-stop gets run in stopping
[06:24] <Keybuk> and then it should go to waiting
[06:25] <Keybuk> initctl hangs is probably the bug
[06:27] <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:29] <AStorm> damned halting problem, eh? :P
[06:34] <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:35] <AStorm> Well, the help would be wrt making udev send upstart events
[06:36] <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:37] <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:38] <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:39] <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] <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:40] <AStorm> (to store the dependencies in upstart scripts)
[06:40] <AStorm> Maybe also some mapping, like: net="network-device-eth0:network-device-eth1"
[06:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:48] <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:49] <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:50] <AStorm> Maybe a tiny extension of the syntax - explicit and?
[06:50] <AStorm> and support for environment vars in calculation of the events/
[06:51] <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:52] <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:53] <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:54] <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:55] <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:56] <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:57] <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:58] <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:59] <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
[07:00] <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:01] <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:02] <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:03] <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:04] <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:05] <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:06] <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:07] <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:08] <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:09] <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:10] <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:11] <Keybuk> right
[07:11] <Keybuk> but then the job doesn't need to care about its deps, surely?
[07:12] <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:13] <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:14] <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:15] <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:16] <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:17] <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:18] <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:19] <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:20] <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:21] <AStorm> Blah, the other way around
[07:22] <AStorm> Ugh, my badness, checked what I passed in the logs :P
[07:22] <Keybuk> it does?
[07:23] <AStorm> No, it doesn't. A brain fart.
[07:23] <Keybuk> :p
[07:24] <AStorm> Hmm, the ChangeLog conflicted :P
[07:24] <AStorm> (expected - the patch is probably against bzr)
[07:24] <Keybuk> yes
[07:25] <AStorm> Ok, now on to more hacking - writing that basic layer
[07:26] <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:27] <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:28] <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:29] <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:30] <AStorm> the pre-start is ran when?
[07:31] <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:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:39] <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:40] <AStorm> I think I'll go with the "multiple files" approach.
[07:41] <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:42] <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:45] <AStorm> Hmm, even the "when" would be too far
[07:45] <AStorm> Just on
[07:46] <AStorm> stop on stopping ourdep
[07:46] <AStorm> Because that's broken in Gentoo init scripts too :P
[07:48] <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:49] <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:50] <AStorm> Simple then.
[07:50] <AStorm> Just read OPTS variable.
[07:51] <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:59] <AStorm> Probably by defining our own bash function, then sourcing. This will override our own definition.
[08:02] <AStorm> Wouldn't it be nice to have the reload event separated from restarting, generally?
[08:03] <AStorm> E.g. special events "reloading xyzzy" "reloaded xyzzy"
[08:04] <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:05] <_ion> That could be useful. Let's ask Keybuk's thoughts about it when he returns.
[08:10] <AStorm> Of course, the states would only be emitted if the event had reload in it.
[08:12] <AStorm> and add the initctl function reload
[08:12] <AStorm> it'd fail if the event wouldn't support it
[08:13] <AStorm> s/wouldn't/didn't/
[08:15] <AStorm> could just fall back to stop/start
[08:16] <AStorm> or just start if not running
[08:30] <AStorm> Temporarily, I'll just create more events
[08:31] <AStorm> Actually, I'll use a parameter.
[08:31] <AStorm> These become just $1, $2 etc?
[08:56] <AStorm> I'm wondering... how to avoid checking filesystems from the same drive in parallel
[08:56] <AStorm> Hmm.
[08:57] <AStorm> Maybe just something simple... I'd do away with the fstab anyway - it'd be parsed.
[09:00] <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:01] <AStorm> LVM can be worked around by parsing lvs
[09:01] <AStorm> But don't know about udev...
[09:03] <_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:04] <_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:05] <AStorm> Great, just great. I shall see.
[09:05] <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:06] <AStorm> Would need physical FS data.
[09:06] <AStorm> Hmm... there is an option...
[09:06] <AStorm> parsing /proc/diskstats
[09:07] <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:09] <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:10] <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:11] <AlexExtreme> which are distro specific
[09:11] <AStorm> :>
[09:11] <arachnist> oh, ok
[09:12] <AStorm> Ok.
[09:12] <AStorm> udevinfo returns the hardware ID.
[09:12] <AStorm> One problem less. Now I'll check the LVM.
[09:17] <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:18] <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:21] <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:22] <Md> I think you are looking for /lib/udev/vol_id
[09:23] <_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:24] <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:25] <AStorm> For knowing the LVM volumes, one just needs to run vgscan - and that's needed anyway
[09:26] <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:27] <_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:28] <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:30] <AStorm> Yes, there is a tool in sysfsutils
[09:30] <AStorm> systool
[09:32] <AStorm> But why depend on an external tool, when few ls or finds will suffice?
[09:32] <AStorm> *a few
[09:33] <AStorm> The basic partitions are just subdirs of the drive subdirectory
[09:34] <AStorm> the device mappings are on their own, but they have the parition(s) they're contained in symlinked in slaves subdir
[09:35] <AStorm> Also, the partitions/discs have the symlink to the mappings in holders
[09:35] <AStorm> subdirectory
[09:36] <AStorm> Simple enough to write a script to detect that in realtime.
[09:38] <AStorm> Only swap partitions will have to be ignored...
[09:39] <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:40] <_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:43] <AStorm> How does one detect that a partition is swap in Linux? :>
[09:43] <AStorm> w/o trying to mount it
[09:45] <AStorm> Ah, right.
[09:45] <AStorm> mount -f -v
[09:46] <AStorm> Blah, that does print unknown only
[09:46] <AStorm> Any ideas?
[10:00] <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:01] <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:03] <AlexExtreme> night
[10:04] <phsdv> night
[10:21] <AStorm> Blah, it's just a syscall, that swapon.
[10:35] <AStorm> Heh, the first page of swap contains a magic ID
[10:36] <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:39] <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:51] <AStorm> In case of problems, I'll just punt and check the largest pagesize
[10:54] <AStorm> Ah, it should be in the libc headers.
[11:00] <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:01] <AStorm> 1 << 22 is... 4MB!
[11:01] <AStorm> Now that's some page :>
[11:04] <AStorm> I'd like to avoid grepping 4 MB of the swapfile, but oh well :P
[11:16] <AStorm> head -n 4m | grep -U SWAPSPACE2 is ok... but..
[11:17] <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:48] <_ion> Keybuk's dinner has taken a while. :-)
[11:51] <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:52] <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:53] <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:54] <_ion> It compiles with the libnih from https://code.launchpad.net/~ion/+branch/libnih/watch-delayed