| === robbiew-afk is now known as robbiew | ||
| === Keybuk_ is now known as Keybuk | ||
| 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:28 |
|---|---|---|
| Keybuk | :p | 17:33 |
| ion | Of course, setsid or screen worked as a workaround, but nevertheless. | 17:34 |
| * Ng curious why -n isn't the default for start/stop | 17:52 | |
| Keybuk | because that would be wrong | 17:52 |
| 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:53 |
| Ng | if it is, then -n should be the default because init scripts don't block forever, right? :) | 17:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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 :) | 17:58 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| Keybuk | eucalyptus-cloud start/post-start, (post-start) process 821 | 18:05 |
| Keybuk | do you see something like that? | 18:05 |
| 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:06 |
| 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:07 |
| 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 |
| Keybuk | <g> | 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:14 | |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| Ng | with pleasure, although it'll be the other side of hometime and dinner :) | 18:23 |
| Keybuk | np | 18:23 |
| Ng | thanks :) | 18:23 |
| === robbiew is now known as robbiew-afk | ||
| PovAddict | can I use upstart on debian? :] | 19:09 |
| 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:14 |
| Keybuk | no hammer required | 19:50 |
| Keybuk | I believe it's as simple as apt-get install upstart | 19:50 |
| sadmac2 | Keybuk: really? I thought they just decided to use it. | 19:51 |
| 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:52 |
| sadmac2 | I guess if you ship two completely different kernels, shipping two init systems isn't a stretch | 19:53 |
| === robbiew-afk is now known as robbiew | ||
| wasabi_ | expect fork. What's that do? | 20:12 |
| wasabi_ | Tracks down the pid's using ptrace? | 20:12 |
| 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:14 |
| ion | Well, duh :-) | 20:15 |
| wasabi_ | Brain fart from a time long past. | 20:15 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!