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