| === rberger_ is now known as rberger | ||
| === h\h is now known as haraldh | ||
| plundra | Hmm! | 15:11 |
|---|---|---|
| plundra | Am I right when I think upstart sets the process-title, to whatever is launched? | 15:12 |
| plundra | Because, when I re-set the process title inside of my application; nothing gets "through" | 15:12 |
| Keybuk | no, Upstart doesn't muck around with the process title of children | 15:13 |
| Keybuk | exec() already takes care of that, after all | 15:13 |
| Keybuk | and it's handy to see the brief period where the child is still "init" | 15:13 |
| plundra | Hmm, so I should be able to change title? | 15:14 |
| Keybuk | yes, don't see why not | 15:17 |
| plundra | HMM! Can't recreate it with an example script :) I'll test some more. Thanks | 15:20 |
| Keybuk | what are you using to set the process title of your application? | 15:20 |
| plundra | It's python, I'm using setproctitle | 15:20 |
| plundra | Worked fine when not launching via the upstart-job, but then I wrote a test which ONLY sets the title and sleeps, using the same routine, which worked just fine. | 15:21 |
| Keybuk | I didn't think Linux implemented setproctitle() :p | 15:22 |
| plundra | I'm pretty sure it uses a few hacks to get it working on different OSs. | 15:22 |
| plundra | Since it works on Linux, OSX, BSD and even Windows. | 15:23 |
| plundra | http://pypi.python.org/pypi/setproctitle/ | 15:23 |
| Keybuk | I'd point out here that you're saying it isn't working on Linux, that's all :p | 15:24 |
| plundra | As I said, it do work outside of upstart with the application I initially wrote, which uses it. But not with upstart. Although, when writing a proof-of-concept, it does indeed work with upstart. Which puzzles me. | 15:28 |
| Keybuk | I can't think of anything "odd" Upstart would do here | 15:29 |
| plundra | Heh, my stupid processes are respawning, didn't see that :-P I wonder what I broke. | 15:29 |
| Keybuk | after all, after the exec() it's a clean environment anyway | 15:29 |
| plundra | Yeah, no, it's me of course :) | 15:29 |
| astsmtl | Hi all! | 15:30 |
| Keybuk | astsmtl: hi | 15:30 |
| astsmtl | Question about upstart in LTS. :) | 15:30 |
| astsmtl | I mean current LTS. | 15:30 |
| astsmtl | Which is Hardy. | 15:30 |
| Keybuk | sure | 15:31 |
| Keybuk | actually, I think both dapper and hardy are technically LTS ;-) | 15:31 |
| Keybuk | dapper doesn't EOL for server until 2011 | 15:31 |
| Keybuk | but since dapper didn't have Upstart ... I'm just digressing | 15:31 |
| astsmtl | I have a simple job def. exec su xxxxxx -c "/usr/bin/Newd --daemon --pid-file=/var/run/Newd/Newd.pid --config-file=/etc/Newd/config.xml" | 15:32 |
| astsmtl | It seems like upstart doesn't catch this daemon. After I start this job it's status is (stop) waiting, and daemon is running. | 15:33 |
| astsmtl | So I can't stop it, respawn won't work... | 15:34 |
| astsmtl | Upstart version is 0.3.9-2. | 15:34 |
| astsmtl | So the question is: "Is it possible to lanch daemon like this in my Upstart?" | 15:35 |
| astsmtl | Also, is it possible with more recent Upstart version? | 15:35 |
| Keybuk | astsmtl: correct, Upstart 0.3.9-2 cannot do that | 15:37 |
| Keybuk | more recent versions can | 15:37 |
| plundra | Why would you want to launch a background deamon from upstart? (It's a real question, I might have missed some use-cases :P) | 15:40 |
| plundra | ae* | 15:40 |
| Keybuk | plundra: most daemons take great care to not daemonise until they're ready to receive connections | 15:40 |
| Keybuk | (for example) | 15:40 |
| Keybuk | so it's a good indication that it's "ready" | 15:40 |
| plundra | Ah, yeah, ok :-) I get that. | 15:41 |
| astsmtl | So, launching a background daemon is a normal use-case for Upstart? | 15:46 |
| astsmtl | plundra: I'm a bit confused with your question. :) | 15:48 |
| plundra | astsmtl: To me it sounds weird, I mean, from what I want out of upstart at least. | 15:49 |
| plundra | I just want it to respawn our applications, if needed :-) Sure beats fire-and-forget from init.d, which was used before. | 15:50 |
| Keybuk | astsmtl: it's supported with 0.6.x | 15:51 |
| astsmtl | plundra: I started looking at upstart jobs because of respawn too. :) | 15:52 |
| astsmtl | Keybuk: Thanks and sorry for my engrish. :) | 15:53 |
| astsmtl | Keybuk: btw, You are Scott James Remnant it seems? | 15:54 |
| Keybuk | yes | 15:54 |
| Keybuk | it sometimes seems that way to me too | 15:54 |
| plundra | I'm planning to try supervisord actually, to see if it's not worse then upstart for what we use it for. Because I like the built in stdout/stderr-logging capabilties, and mail notifications. | 15:55 |
| plundra | Since I've added those two things with horrible hacks in my upstart-jobs :-P | 15:55 |
| Keybuk | yeah | 15:55 |
| Keybuk | ENOTIME ;-/ | 15:55 |
| astsmtl | Keybuk: Thanks for livef1. I even tried to rewrite it in python as a library, but didn't finish. :) | 15:56 |
| sadmac2 | after all the time I spent trying not to hack on libnih, its all I've been doing lately | 16:02 |
| Keybuk | sadmac2: ;) | 16:07 |
| Keybuk | me too | 16:07 |
| Keybuk | the third iteration of the epoll stuff is starting to look awesome | 16:08 |
| DuckFault | does upstart provide a mechanism to get all events generated during early boot? | 16:08 |
| Keybuk | DuckFault: not at the moment | 16:08 |
| sadmac2 | Keybuk: I still have most of that triggers stuff sitting in my dusty 0.6 tree. Not sure if it still merges even. | 16:08 |
| DuckFault | Its very annoying debugging bootup with a read only root and having no syslog started and having issues with upstart. | 16:09 |
| Keybuk | yeah, I think I want the ability to be able to ask upstart "so, what did you get up to today?" | 16:09 |
| DuckFault | granted it was an embedded device with no video and no serial out, but those shouldn't be necessary | 16:09 |
| Keybuk | and have a good event log | 16:10 |
| Keybuk | not just what events happened, but what upstart did as a result | 16:10 |
| DuckFault | you can't have a forever event log, but at least a last 5 minutes or something | 16:10 |
| Keybuk | ie. "net-device-up eth0" => "started apache" etc. | 16:10 |
| DuckFault | yes, that would be immensely beneficial | 16:10 |
| Keybuk | it doesn't need to be "forever", a ring log would be fine | 16:10 |
| DuckFault | but just an event list would work for me | 16:10 |
| Keybuk | once you have a filesystem you could opt to log it there | 16:10 |
| DuckFault | I figure if you're in the guts enough to need to know what events occurred and what their actions are, you know enough where to see what actions would get initiated by said events. | 16:11 |
| Keybuk | actually, that's the thing | 16:13 |
| Keybuk | often when debugging, it's assuming what does happen being different to what actually happened that's the bug | 16:14 |
| Keybuk | so I usually need to know whether upstart actually *did* start a job | 16:14 |
| Keybuk | and if not, why not, etc. | 16:14 |
| sadmac2 | Keybuk: a quick fix for a lot of these logging questions might be to do a 0.6.6 with some systemtap/perf/$footracer probe points shoved in. | 16:16 |
| Keybuk | sadmac2: interesting | 16:17 |
| Keybuk | what you call a quick fix I call "argh, hard!" | 16:17 |
| Keybuk | suggestion systemtap as a quick fix for a lack of logging is like suggesting amputation as a quick fix for a splinter | 16:18 |
| sadmac2 | Keybuk: one or two plus the tracer stuff would do it. Then you just "probe upstart.event { printf("%s %s", $upstart_event, $upstart_args) } | 16:18 |
| sadmac2 | last I looked at them they were pretty easy to put in... maybe I should look again. | 16:19 |
| ion | http://zi.fi/shots/clang.png | 22:53 |
| === robbiew is now known as robbiew_ | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
