[17:28] <ion> It’s awesome you can run ‘restart gdm’ from an X terminal and still have gdm come back up, as opposed to ‘service gdm restart’ back when gdm was an init.d service. :-P
[17:33] <Keybuk> :p
[17:34] <ion> Of course, setsid or screen worked as a workaround, but nevertheless.
[17:52]  * Ng curious why -n isn't the default for start/stop
[17:52] <Keybuk> because that would be wrong
[17:53] <ion> Indeed
[17:53] <Ng> I'm assuming that start is an appropriate command to use as a substitude for /etc/init.d/blah start
[17:54] <Ng> if it is, then -n should be the default because init scripts don't block forever, right? :)
[17:55] <ion> init.d scripts block until they inform you about whether the action you requested succeeded.
[17:55] <Ng> perhaps the upstart jobs for eucalyptus are just Wrong[tm], but it kinda seems like it's a bit of a gamble which services will return be to a prompt when I do start foo, and which will just wait forever
[17:55] <Keybuk> Ng: start doesn't block forever either
[17:56] <Keybuk> start only blocks until the service is *running*
[17:56] <Keybuk> and that's why -n isn't the default
[17:56] <Keybuk> start dbus
[17:56] <Keybuk> start hal
[17:56] <Keybuk> works
[17:56] <Keybuk> start -n dbus
[17:56] <Keybuk> start -n hal
[17:56] <Keybuk> doesn't
[17:56] <Keybuk> (dbus isn't yet listening when you try and start hal)
[17:56] <Ng> Keybuk: how does it determine the running state?
[17:56] <Ng> I'm just curious because I did "start eucalyptus-cloud" and I want my shell prompt back ;)
[17:56] <Keybuk> Ng: exec() caused a close-on-exec file descriptor to be closed
[17:57] <Keybuk> briefly looking here, but the eucalyptus jobs seem to have code to poll the service until it's actually running
[17:57] <Keybuk> so I assume because eucalyptus is still starting
[17:57] <Ng> hmm
[17:57] <Ng> fair enough
[17:58] <Ng> that's quite annoying, but clearly not your problem :)
[17:58] <Keybuk> if you look at /etc/init/eucalyptus-cloud.conf you'll see it has a post-start script
[17:58] <Keybuk> mdz has put that in there deliberately
[17:58] <Ng> it all starts up fine if you just let it, or at least it did in jaunty when the init scripts just forked everything off and let it sort itself out
[17:58] <Ng> but that's not your problem, so I will take my whining elsewhere. thanks :)
[18:00] <Ng> oh! there was one other tiny little whine I wanted to raise before filing a bug :)
[18:00] <Keybuk> I think you're probably supposed to use "start eucalyptus" looking at it
[18:01] <Ng> I was wondering if the output from start/stop/status could be made a little more verbose
[18:01] <wasabi_> Oh looky!
[18:01] <wasabi_> We're actually using upstart now!
[18:02] <Ng> (mainly so it would explicitly say what the current state is, atm i think it's prone to interpretation)
[18:02] <Keybuk> it does explicitly say?
[18:02] <Keybuk> warcraft scott% status dbus
[18:02] <Keybuk> dbus start/running, process 821
[18:03] <wasabi_> This is very refreshing.
[18:03] <wasabi_> To see all these .conf files.
[18:03] <wasabi_> Though somehow fsck runs twice on boot for me. Once after the file systems are mounted.
[18:03] <wasabi_> And then it fails.
[18:03] <Keybuk> wasabi_: odd.
[18:03] <Ng> Keybuk: I was thinking that just sprinkling in a few more words would make it much clearer.. "dbus is running as process 821"
[18:03] <Keybuk> Ng: the status output is intended to be grep/sedable
[18:03] <wasabi_> Guessing the mount process is kicked off by a successful fsck
[18:03] <wasabi_> And it mounts things other than the devices that was fscked
[18:04] <wasabi_> 'guessing'.
[18:04] <Keybuk> Ng: not sure I follow though, maybe I'm used to it, but it seems fairly clear
[18:04] <Keybuk> the only confusing bits come when you get post-start scripts ;)
[18:05] <Keybuk> eucalyptus-cloud start/post-start, (post-start) process 821
[18:05] <Keybuk> do you see something like that?
[18:06] <Keybuk> actually, I think that's even clear now
[18:06] <Keybuk> eucalyptus-cloud start/post-start, process 821
[18:06] <Keybuk> no?
[18:06] <ion> keybuk: How about cmd="$(eval start --sh foo)"; eval "$cmd"; printf "%s, %s\n" "$upstart_status" "$upstart_pid"? :-P
[18:06] <Ng> Keybuk: so like just now I had it stopped and it said "eucalyptus-cloud: stop/waiting"
[18:06] <Keybuk> ion: ?
[18:06] <Keybuk> Ng: right...
[18:06] <ion> Whoops, cmd="$(start --sh foo)"
[18:06] <Keybuk> Ng: that seems to be clearly "it's stopped, and I'm waiting for you tell me otherwise" ?
[18:06] <ion> An alternative to seding the start output: have it output sh commands that set environment variables
[18:07] <Keybuk> ion: dbus-send is your friend ;)
[18:07] <Ng> Keybuk: isn't it always waiting to be told something? I was wondering if maybe there could be "stopping" and "stopped"
[18:08] <Keybuk> ion: 
[18:08] <Keybuk> warcraft scott% sudo dbus-send --address=unix:abstract=/com/ubuntu/upstart --type=method_call --print-reply /com/ubuntu/Upstart/jobs/dbus/_ org.freedesktop.DBus.Properties.Get string:com.ubuntu.Upstart0_6.Instance string:processes
[18:08] <Keybuk> method return sender=(null sender) -> dest=(null destination) reply_serial=1
[18:08] <Keybuk>    variant       array [
[18:08] <Keybuk>          struct {
[18:08] <Keybuk>             string "main"
[18:08] <Keybuk>             int32 821
[18:08] <Keybuk>          }
[18:08] <Keybuk>       ]
[18:08] <Keybuk> --

[18:08] <ion> I wish dbus-send could output data in format one can easily parse from a sh script. :-P
[18:08] <Keybuk> Ng: no, the only two times it's ever only waiting for commands are "waiting" and "running"
[18:09] <Keybuk> ion: you could write such a tool
[18:09] <ion> Sure
[18:09] <Keybuk> Ng: it's a bit subtle
[18:09] <Keybuk> for example
[18:09] <Keybuk> consider the state "stop/running" :)
[18:09] <Keybuk> and "start/waiting"
[18:09] <Keybuk> they do exist, they're just a bit brief
[18:09] <Ng> stop/running makes no sense to my human eyes ;)
[18:09] <Keybuk> sure
[18:09] <Keybuk> someone told the service to be stopped
[18:09] <Keybuk> but it's still running
[18:09] <Ng> I know what you mean, but I am a simple human wanting to know what my services are doing
[18:09] <ion> ng: Goal: stop, status: running
[18:09] <Ng> I'm all for a seddable/greppable interface, but maybe some extra words would help
[18:10] <Keybuk> simple humans can use the nice GUI I'll write one day ;)
[18:10] <Ng> I'm a simple human on a server :)
[18:10] <Keybuk> Ng: though if you can come up with output that makes sense, I'm all ears ;)
[18:10] <Keybuk> the problem is that words like "starting" and "stopping" are *VERY* specific in Upstart world
[18:10] <Keybuk> so having upstart use them badly would be confusing
[18:11] <Keybuk> I guess you'd want
[18:11] <Keybuk> status --dummy dbus
[18:11] <Keybuk> dbus is running
[18:11] <Keybuk> status --dummy apache
[18:11] <Keybuk> apache will be stopped
[18:11] <Keybuk> status --dummy hal
[18:11] <Keybuk> hal will be started
[18:11] <Keybuk> status --dummy obby
[18:11] <Keybuk> obby is being restarted
[18:11] <Keybuk> ?
[18:12] <Ng> that seems better, although "will be" makes me wonder what those are conditional upon
[18:12] <Keybuk> (along with "is not running", those are probably the basic meta-states)
[18:12] <ion> gdm: goal=start status=running process=42 – how about that for both humans and parsing?
[18:12] <Keybuk> Ng: if you do "start apache" (or someone else does)
[18:12] <Keybuk> then it'd be "is being restarted" :p
[18:14] <Ng> how abouy just having an option that spits out machine-readable status, otherwise plain english on the assumption that a simple human wants to know if something is broken?
[18:14] <Ng> "foo is running as process N", "foo is not running", "foo is starting", "foo is stopping" kidna thing
[18:14] <Keybuk> it depends on how much information you think the single humans want to know
[18:14] <Keybuk> I could kill both birds with one stone
[18:14]  * Keybuk has AN IDEA
[18:15] <Keybuk> how about, if it's running (and your on a suitable terminal)
[18:15] <Keybuk> the entire text is GREEN
[18:15] <Keybuk> and if it's falling over or stopped or whatever it's RED
[18:15] <Keybuk> and if it's restarting, it's ORANGE
[18:15] <Keybuk> then you can glance at the colour, and not read the scary text ;)
[18:16] <Ng> colour is good for me, I have advanced terminals and no vision defects
[18:16] <Ng> I suspect there is a middle ground that just adapts what you have to be more definitive
[18:17] <Ng> what about changing the tense of the first state bit?
[18:17] <Ng> start->started, stop->stopped
[18:17] <Ng> "stopped/waiting" seems clearer than "stop/waiting"
[18:17] <Keybuk> again, those are very specific words in upstart parlance
[18:17] <Keybuk> a job can be stop/stopped
[18:17] <Keybuk> and start/stopped
[18:17] <Keybuk> so, you'd have the very very strange output
[18:18] <Keybuk>   started/stopped
[18:18] <Keybuk> and
[18:18] <Keybuk>   stopped/started
[18:18] <Keybuk> ;)
[18:18] <Ng> start/stopped is very strange output
[18:18] <Ng> imho
[18:18] <Keybuk> actually that's very meaningful
[18:18] <Keybuk> it tells you that the service is going to be restarted, most likely as a result of a job with "... on stopped YOURJOB" in its conf
[18:18] <ion> I’m still proposing saying “this is the *goal* and this is the *status*” in the output. :-P
[18:19] <Ng> if I read a bunch of upstart docs. I hope I'm not seeming obtuse, I'm deliberately tryign to be a busy sysadmin who loves the idea of upstart, but hasn't read the docs
[18:19] <Keybuk> but yes
[18:19] <Keybuk> I do appreciate your point ;)
[18:19] <Keybuk> the current status command outputs the exact upstart goal/state combo
[18:19] <Keybuk> it should simplify that
[18:20] <Keybuk> you don't need to know the difference between start/starting, start/spawned, start/started & start/running (or stop/stopping, stop/killed, stop/stopped & stop/waiting)
[18:20] <Keybuk> not unless you're debugging anyway
[18:20] <Ng> yeah
[18:20] <Ng> I definitely want to be able to choose to see those
[18:20] <Keybuk> the simplified model actually makes this simpler anyway
[18:20] <Ng> but mostly I just want someone to hug me and tell me apache is running properly ;)
[18:20] <Keybuk> since it reduces the states to starting, started, stopping & stopped anyway
[18:21] <Keybuk> (intermediate states)
[18:21] <Keybuk> Ng: I guess you do want to know whether apache is still starting or not
[18:21] <Ng> sure
[18:22] <Ng> and by "sure" I mean "definitely, that's the kind of newfangled awesomeness I want from upstart"
[18:22] <Keybuk> could you file an upstream bug?
[18:23] <Ng> with pleasure, although it'll be the other side of hometime and dinner :)
[18:23] <Keybuk> np
[18:23] <Ng> thanks :)
[19:09] <PovAddict> can I use upstart on debian? :]
[19:14] <sadmac2> PovAddict: be our guest :)
[19:14] <sadmac2> PovAddict: they don't ship it yet (soon) but there's no reason it won't work if you want to hammer it in there yourself.
[19:50] <Keybuk> no hammer required
[19:50] <Keybuk> I believe it's as simple as apt-get install upstart
[19:51] <sadmac2> Keybuk: really? I thought they just decided to use it.
[19:52] <Keybuk> sadmac2: it's been installable for yeras
[19:52] <Keybuk> the decision was about it being the default
[19:52] <sadmac2> ahh, debian. Is there anything they won't make pluggable?
[19:53] <sadmac2> I guess if you ship two completely different kernels, shipping two init systems isn't a stretch
[20:12] <wasabi_> expect fork. What's that do?
[20:12] <wasabi_> Tracks down the pid's using ptrace?
[20:14] <wasabi_> Also... why do we still spawn recovery consoles asking for the root password?
[20:14] <wasabi_> Since we don't even set a root password.
[20:14] <wasabi_> That would seem braindead at this point.
[20:14] <ion> Huh? My recovery anything doesn’t as for root password.
[20:14] <wasabi_> root@station-1:~# sulogin
[20:14] <wasabi_> Give root password for maintenance
[20:14] <wasabi_> (or type Control-D to continue):
[20:14] <wasabi_> Oh maybe it only does it if you have one. :)
[20:15] <ion> Well, duh :-)
[20:15] <wasabi_> Brain fart from a time long past.