| Jordan_U | I just asked thufir_ to come here from #ubuntu because they appear to have a defunct process whose parent is PID 1, which shouldn't be possible. | 00:01 |
|---|---|---|
| thufir_ | what you should I about a defunct process owned by init? | 00:02 |
| Jordan_U | Sounds similar to https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1077579 , and I've seen at least 4 other people with the what appears to be the same bug at various times from #ubuntu. | 00:02 |
| thufir_ | http://pastebin.com/vwfiZKKv ps -p 12557 -o ppid if that link works. | 00:03 |
| thufir_ | that's weird. I mean, I could restart, but while we're here, what's init? is that like root? | 00:03 |
| thufir_ | Jordan_U: oh, how do I file a bug? bug .... | 00:05 |
| Jordan_U | thufir_: Init is the first process run in a *NIX system, and never dies (if init ever dies, the kernel panics and everything stops). Among other jobs, it is supposed to be the parent of all orphaned processes, and reap them whenever they die. PID 1, i.e. init, i.e. upstart appears to be failing at this basic job. | 00:07 |
| thufir_ | yeah, I was reading about that in man page. | 00:07 |
| Jordan_U | thufir_: I don't know if it's best to file a new bug report or say that one of the existing reports affects you too. Hopefully someone here will respond (wait a while, at least an hour). If nobody does, then file a new bug report but mention that it may be a duplicate of https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1077579 . | 00:08 |
| thufir_ | Jordan_U: that's ok, no worries. I'll just reboot. I'll add a comment to that bug, wrote down the #. thanks. I'm all set now, nothing to do. Just wanted to know if there was something I could do. | 00:10 |
| Jordan_U | thufir_: Well someone here might have a test they'd like you to run. | 00:11 |
| thufir_ | Jordan_U: ok | 00:14 |
| * thufir_ hangs about :) | 00:14 | |
| Jordan_U | thufir_: Thanks. I've been wondering about this bug for a while, I'd love to know why/how it's happening :) | 00:15 |
| thufir_ | ok. hawat.thufir@gmail.com by the way | 00:15 |
| thufir_ | 12.10 server edition, installed from that and added xubuntu desktop | 00:16 |
| Jordan_U | thufir_: Do you use Samba? | 00:23 |
| thufir_ | nope. not installed, let me check. | 00:24 |
| thufir_ | oh, I'm installing chromium-browser, but I'm positive that I don't use samba. | 00:24 |
| thufir_ | Jordan_U: I do have samba installed! | 00:43 |
| Jordan_U | thufir_: There was speculation that the linked bug might be related to https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1075923 , but unless you had mounted a samba share via Thunar I think we can rule that out (for you at least). | 00:45 |
| thufir_ | I'm using thunar... | 00:45 |
| thufir_ | and have two hard drives. | 00:45 |
| thufir_ | but, I have no idea what samba is. I'll read wikipedia. | 00:46 |
| thufir_ | I can't imagine why I have samba installed, it's only Linux on this box. there used to be windows, so maybe it's a holdover. I'll look into mounting a share via thunar. | 00:49 |
| Jordan_U | thufir_: Samba is a very common way to share files over the network, even when you're only sharing among *NIX machines, but you would know if you'd been mounting networked filesystems. | 00:54 |
| thufir_ | ok, not networked. just | 00:56 |
| thufir_ | Jordan_U: still want me to hang around? | 01:30 |
| Jordan_U | thufir_: I guess not. Please do file a bug report though, with the output of "ps aux" and ps -p 12557 -o ppid, and the output of "dmesg" in case there's anything interesting there. | 01:33 |
| thufir_ | got it. | 01:34 |
| Jordan_U | thufir_: Thanks for taking the time to file a bug report. | 01:39 |
| thufir_ | lol, what's the command again? | 01:41 |
| thufir_ | I'm looking at https://help.ubuntu.com/community/ReportingBugs. i'll let you know. | 01:42 |
| === ion_ is now known as ion | ||
| === elmo__ is now known as elmo | ||
| === SpamapS_ is now known as SpamapS | ||
| === stgraber_ is now known as stgraber | ||
| === SpamapS_ is now known as SpamapS | ||
| chras | so i had a requestion: re upstart environment. | 18:56 |
| chras | if i have a ver pre-defined in my upstart script, ie. env FOO=${some_value} | 18:56 |
| chras | and then issue a start with FOO=${some_other_value} | 18:56 |
| chras | then the entire lifetime of that execution has FOO=${some_other_value} | 18:57 |
| chras | ie, even during a stop | 18:57 |
| SpamapS | no | 18:57 |
| chras | well | 18:57 |
| chras | yes | 18:57 |
| chras | thats the case | 18:57 |
| SpamapS | that instance will get some_other_value | 18:58 |
| SpamapS | stop will destroy the instance | 18:58 |
| chras | we're saying the same thing | 18:58 |
| chras | once we stop it, i dont care | 18:58 |
| chras | im talking about lifetime of start -> stop | 18:58 |
| SpamapS | restart will not | 18:58 |
| chras | anyways, my question is thus | 18:59 |
| chras | is there any way for it to automatically use the predefined value | 18:59 |
| chras | UNLESS its specified on cmdline | 18:59 |
| SpamapS | ahh yes | 18:59 |
| SpamapS | during stop, got it | 18:59 |
| chras | so if i doo FOO=bar on cmdline | 18:59 |
| chras | i want that to be true in that incarnation | 18:59 |
| chras | but if i do a stop later | 19:00 |
| chras | can i have to fall back to the predefined value | 19:00 |
| chras | instead of preserving the bar | 19:00 |
| chras | im my exact case, i pass my event a force flag | 19:01 |
| chras | and i wanted to avoid having two force flags | 19:01 |
| SpamapS | so start creates an instance of your job | 19:01 |
| chras | once for startup, and one for stop | 19:01 |
| SpamapS | passing FOO=bar to start makes FOO=bar for that instance | 19:01 |
| chras | yup | 19:01 |
| SpamapS | stopping that instance, removes all memory of FOO=bar | 19:01 |
| chras | can i can overwrite that with stop FOO=something_else | 19:01 |
| SpamapS | so a subsequent 'start' will pick up 'env FOO=baz' from the job definition because you did not pass anything to start. | 19:02 |
| chras | yup | 19:02 |
| chras | know that | 19:02 |
| SpamapS | no you can't change environment variables on a running instance | 19:02 |
| chras | thats what i figured | 19:02 |
| chras | so ill have to two use diff vars | 19:02 |
| SpamapS | use a file on disk to affect the post/pre stop scripts | 19:03 |
| chras | bleh, have to use two diff | 19:03 |
| chras | thats messy in my case, its easier to have FORCE_FLAG_WHEN_STARTING vs FORCE_FLAG_WHEN_STOPPING | 19:03 |
| SpamapS | hm | 19:03 |
| chras | since when i send my force flag during startup, i dont neccecerily want that set during stop | 19:03 |
| SpamapS | stop does list KEY=VALUE in the man page | 19:03 |
| chras | so ill just have to disjoint them | 19:03 |
| SpamapS | so I may be wrong | 19:04 |
| chras | im likely doing a bad job explaining my situation | 19:04 |
| SpamapS | no I get it perfectly | 19:04 |
| SpamapS | and I think its a valid use case | 19:04 |
| chras | youc an do stop VAR= | 19:05 |
| chras | and it works fine | 19:05 |
| chras | on startup i set a force flag in some situations | 19:15 |
| chras | and i ALSO need a force flag in some stop situations | 19:15 |
| chras | but thoes are not the same | 19:15 |
| SpamapS | ah ok, I think the KEY=value is just for locating multi-instance jobs | 19:15 |
| chras | so havign it be global is problematic | 19:15 |
| chras | well | 19:15 |
| chras | thats if you use the env in your $INSTANCE | 19:15 |
| chras | var | 19:15 |
| SpamapS | so like when you've done 'instance $FOO' in your job, you can do 'start myjob FOO=1; start myjob FOO=2;stop myjob FOO=1;' | 19:16 |
| chras | yup | 19:16 |
| * SpamapS is reading the code at this point | 19:16 | |
| chras | instance can be wahtever you want mind you, ie can be "chris-$var1-$var2-$varN" | 19:16 |
| SpamapS | having done some really crazy stuff w/ instance (note /etc/init/wait-for-state.conf) .. I'm fully aware :) | 19:16 |
| chras | what i was hoping for was there was a way to say, FOO=${whats_defined_in_the_event_always} UNLESS, its specified on the command line | 19:16 |
| chras | so if i did a stop on an event | 19:16 |
| SpamapS | http://bazaar.launchpad.net/~upstart-devel/upstart/trunk/view/head:/init/job_class.c#L1060 | 19:16 |
| SpamapS | chras: comment confirms, args are not passed to the job during stop | 19:16 |
| chras | then it would take wht was pre-defined, instead of what was set when it was specified on the cmdline during the start | 19:17 |
| chras | sure they are | 19:17 |
| chras | May 13 19:12:29 t-nfs04b init: (env_test post-start): Value of CHRIS=[PREDEFINED] | 19:17 |
| chras | May 13 19:12:36 t-nfs04b init: (env_test pre-stop): Value of CHRIS=[stopingvar] | 19:17 |
| chras | root@t-nfs04b:~# initctl start env_test | 19:17 |
| chras | root@t-nfs04b:~# initctl stop env_test CHRIS=stopingvar | 19:17 |
| SpamapS | chras: oh so it does work the way you want. Interesting! | 19:17 |
| chras | well no | 19:17 |
| chras | thats the expected behaviour | 19:17 |
| chras | if i do this | 19:17 |
| chras | initctl start env_test CHRIS=startingval | 19:17 |
| chras | and then do ao | 19:17 |
| chras | initctl stop env_test | 19:17 |
| chras | with NO cmdline | 19:17 |
| chras | id 'expect' it to be | 19:17 |
| chras | CHRIS=[PREDEFINED] | 19:17 |
| chras | instead, its CHRIS="startingval" | 19:17 |
| SpamapS | yeah I'm just surprised it is passed into the pre-stop/post-stop | 19:17 |
| SpamapS | yeah, but you see now why | 19:17 |
| SpamapS | You'd need a special case thing ot initctl, like '--restore-predef' ... seems pretty complicated. | 19:17 |
| chras | yup | 19:17 |
| chras | so i think, best bet for me, is just to have TWO variables | 19:17 |
| chras | one to force things during startup | 19:17 |
| SpamapS | or a DEFAULT_FOO and then pass in USE_DEFAULT=1 | 19:17 |
| chras | and once to force things during stopping | 19:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!