[02:27] <coshx> i'm debugging an upstart conf, but "sudo start myjob" and "sudo stop myjob" are freezing. I can ctrl+c out, but to get back to normal behavior, I have to reboot. the only change in /var/log is to auth.log (because of sudo). strace shows it freezing at "poll([{fd=3, events=POLLIN}], 1, -1", but I'm not sure what this means.
[02:45] <coshx> I'm guessing that fd is from connect(3, {sa_family=AF_FILE, path=@"/com/ubuntu/upstart"}, 22) = 0 -- is that a dbus socket?
[02:50] <ion> Please pastebin the config.
[02:52] <coshx> ion: http://gist.github.com/603892 <-- this is what I had (for debugging). It worked as expected a couple times, but then when I called "sudo stop cruise" it froze. I was debugging by calling initctl reload-configuration and then start/stop
[02:53] <ion> Your program most likely doesn’t behave as “expect daemon” expects and the current version of Upstart gets confused.
[02:54] <ion> Ah, it’s an sh script. Yeah, every external command ran by it consists of a fork and an exec, and Upstart follows the first fork and waits for the second one.
[02:54] <ion> Better drop the “expect” stanza if you don’t know *precisely* how the main program behaves regarding forks.
[02:54] <ion> Upstart 0.10 will handle forking programs much better.
[02:55] <coshx> interesting. the actual process should daemonize, but I'll remove the expect and see if I get the behavior I want
[02:57] <coshx> after removing that line, start/stop still freeze -- i'm guessing I have to restart the init process?
[02:57] <coshx> (the only way I know how to do that is to restart)
[02:59] <ion> Yeah, the job is a confused state, expecting for the first command ran by the sh script to finish daemonizing. If rebooting isn’t a problem, that’s the fastest way to get Upstart to a good state.
[03:04] <ion> The fork-following code is a simple initial implementation that only supports two specific use cases (which don’t include most sh scripts), and as i said, a much better replacement is in the works.
[03:07] <coshx> nice, i just don't daemonize the process and don't use 'expect' and it works perfectly! :)  Thanks for explaining to me
[03:24] <coshx> thanks! btw, when I do console output, should I be able to cat /dev/console and see output of the command? I assume this wouldn't show output from a fork though, right?
[03:29] <ion> It might be best to log to a file and read that.
[03:29] <ion> In a future release, the console stanza will support logging.
[03:30] <ion> The simplest style:
[03:30] <ion> script
[03:30] <ion>   exec >/path/to/log 2>&1
[03:30] <ion>   (the rest)
[03:30] <ion> end script
[03:35] <coshx> oh nice. i saw that on the wiki, but didn't realize it directs all output for the script to the logfile.
[13:06] <anymous> hello, how can i stop an upstart job that is defined as "task"?  the command "stop job" gives: stop: Unknown instance: under Lucid.
[13:09] <ion> Are you sure it’s running?
[13:09] <anymous> I think the problem with "tasks" is that they are listed as "stop/waiting"
[13:10] <anymous> although they have been running (doing their "task").
[13:11] <ion> That’s the point of tasks.
[13:11] <anymous> this is true for all jobs marked as tasks, like rcS, rc, mountall-shell, ...
[13:11] <anymous> but some of them have a "pre-stop" section 
[13:11] <ion> Please see init(5), look up the definition of task under “Services, tasks and respawning”.
[13:12] <anymous> I have read the manpage, but it doesn't answer the question how can you invoke initclt so that the pre-stop section is executed.
[13:14] <ion> If the job has stopped successfully, the pre-stop part has been executed.
[13:14] <anymous> ok, just do "stop rcS" it does nothing but print "stop: Unknown instance:"
[13:14] <ion> Yes, it’s not running.
[13:14] <anymous> arg, so the post-script is never executed and thus quite superfluous, no?
[13:15] <anymous> IOW you cannot have a task that defines a stop action.
[13:15] <ion> The post-stop script has been executed when job stopped.
[13:16] <anymous> i don't think so
[13:16] <ion> If you’re sure about that, please file a bug report. But i’m somewhat skeptical, since the unit tests should have caught that long before such a bug ever made it into the Ubuntu archive.
[13:17] <ion> Not to mention that such a bug would probably result in a non-booting system.
[13:17] <anymous> hm, so how can i invoke the stop action of a task manually?
[13:18] <ion> You don’t really do that directly. You can only tell running tasks to stop, which results in the {pre,post}-stop scripts being executed.
[13:18] <anymous> but only if the status is running.
[13:18] <ion> Sure. How would one stop something that is not running?
[13:18] <anymous> right, you said that.
[13:19] <anymous> ok, my example: 
[13:19] <anymous> I have an upstart script that mounts a special directory
[13:20] <anymous> it seems i cannot use stop(8) to invoke the stop action of that job
[13:20] <anymous> because the status after boot of that job is stop/waiting
[13:20] <anymous> although of course the directory is mounted
[13:20] <ion> foo.conf:
[13:21] <ion> pre-start exec mount /foo
[13:21] <ion> post-stop exec umount /foo
[13:21] <ion> No task
[13:21] <anymous> ah! no task, alright, i think i have to try that.
[13:22] <anymous> would it work with  script sections, (script, pre-stop)?
[13:22] <ion> Task means you want everything to run when started, including the {pre,post}-stop scripts at the end.
[13:22] <ion> pre-start script … end script, post-stop script … end script
[13:23] <anymous> thanks for pointing that out, will try it.
[13:24] <ion> Service means your job goes to a certain state (such as directory mounted or daemon running) when started and only does any stop actions when something external causes it to stop.
[13:26] <anymous> does a service not always require a daemon, a running process?
[13:26] <ion> It’s optional
[13:27] <anymous> ok, give me a few reboots...
[13:41] <anymous> no joy, i removed the "task" but still cannot invoke the stop action
[13:43] <ion> What does “status jobname” print? What appears in syslog when you run “start jobname”?
[13:44] <anymous> status: stop/waiting, start gives: start/running, process 2079
[13:45] <mbiebl> anymous: please pastebin your current job file
[13:45] <anymous> not familiar with pastebin :-(
[13:46] <ion> There probably should be no process ID if there’s no main process.
[13:46] <ion> And there shouldn’t be a main process in your job.
[13:46] <anymous> right, theres no process running after the mount
[13:47] <anymous> but i think it's similair to rcS, you can't run "stop rcS"
[13:47] <ion> No, more like apport
[13:48] <mbiebl> http://lmgtfy.com/?q=pastebin
[13:48] <anymous> ok, when I do "stop apport" it also gives: stop: Unknown instance:
[13:49] <anymous> mmbiebl: thanks ;)
[13:49] <ion> That’s because you have apport disabled. The structure of the job should be similar nevertheless.
[13:51] <anymous> http://pastebin.com/ZfP8mSAu
[13:52] <ion> Replace ‘script’ with ‘pre-start script’
[13:52] <ion> You don’t want a main process for that job.
[13:53] <ion> Also, there’s a space between ‘runlevel’ and its parameter.
[13:54]  * anymous is correcting
[14:05] <anymous> http://pastebin.com/nxQcu7Vh but still ... status: stop/waiting
[14:06] <anymous> when you enable apport, its status is running after boot?
[14:07] <ion> Yes
[14:07] <anymous> without a process?
[14:08] <ion> Yes
[15:02] <anymous> thanks for you patience, somehow the status of my job (stop/waiting) is wrong after boot, but i've found a workaround for that.
[17:57] <BLZbubba> i like the verbose boot option; but is there a way to have upstart log to a file?  /var/log or /tmp or whatever?
[17:57] <BLZbubba> i am using a console-less machine and it fails to start everything
[17:58] <BLZbubba> after awhile i can start the network by hand and run "init 2"
[17:58] <BLZbubba> but this is not ideal
[18:09] <rawler> has "initctl events" been remove to trace upstart events?
[18:09] <rawler> ergmh, sprinkle the last statement with some grammar, please..
[18:42] <BLZbubba> heh
[18:45] <mbiebl> BLZbubba: w/r/t logging, no there is not
[21:36] <indygreg> is there any workaround for the non-valid PID stuck in the killed state? I think it is bug #406397. i.e. I want to force mark a job as stopped/having no PID