[02:27] 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] 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] Please pastebin the config. [02:52] 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] Your program most likely doesn’t behave as “expect daemon” expects and the current version of Upstart gets confused. [02:54] 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] Better drop the “expect” stanza if you don’t know *precisely* how the main program behaves regarding forks. [02:54] Upstart 0.10 will handle forking programs much better. [02:55] interesting. the actual process should daemonize, but I'll remove the expect and see if I get the behavior I want [02:57] after removing that line, start/stop still freeze -- i'm guessing I have to restart the init process? [02:57] (the only way I know how to do that is to restart) [02:59] 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] 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] nice, i just don't daemonize the process and don't use 'expect' and it works perfectly! :) Thanks for explaining to me [03:24] 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] It might be best to log to a file and read that. [03:29] In a future release, the console stanza will support logging. [03:30] The simplest style: [03:30] script [03:30] exec >/path/to/log 2>&1 [03:30] (the rest) [03:30] end script [03:35] oh nice. i saw that on the wiki, but didn't realize it directs all output for the script to the logfile. [13:06] 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] Are you sure it’s running? [13:09] I think the problem with "tasks" is that they are listed as "stop/waiting" [13:10] although they have been running (doing their "task"). [13:11] That’s the point of tasks. [13:11] this is true for all jobs marked as tasks, like rcS, rc, mountall-shell, ... [13:11] but some of them have a "pre-stop" section [13:11] Please see init(5), look up the definition of task under “Services, tasks and respawning”. [13:12] 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] If the job has stopped successfully, the pre-stop part has been executed. [13:14] ok, just do "stop rcS" it does nothing but print "stop: Unknown instance:" [13:14] Yes, it’s not running. [13:14] arg, so the post-script is never executed and thus quite superfluous, no? [13:15] IOW you cannot have a task that defines a stop action. [13:15] The post-stop script has been executed when job stopped. [13:16] i don't think so [13:16] 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] Not to mention that such a bug would probably result in a non-booting system. [13:17] hm, so how can i invoke the stop action of a task manually? [13:18] 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] but only if the status is running. [13:18] Sure. How would one stop something that is not running? [13:18] right, you said that. [13:19] ok, my example: [13:19] I have an upstart script that mounts a special directory [13:20] it seems i cannot use stop(8) to invoke the stop action of that job [13:20] because the status after boot of that job is stop/waiting [13:20] although of course the directory is mounted [13:20] foo.conf: [13:21] pre-start exec mount /foo [13:21] post-stop exec umount /foo [13:21] No task [13:21] ah! no task, alright, i think i have to try that. [13:22] would it work with script sections, (script, pre-stop)? [13:22] Task means you want everything to run when started, including the {pre,post}-stop scripts at the end. [13:22] pre-start script … end script, post-stop script … end script [13:23] thanks for pointing that out, will try it. [13:24] 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] does a service not always require a daemon, a running process? [13:26] It’s optional [13:27] ok, give me a few reboots... [13:41] no joy, i removed the "task" but still cannot invoke the stop action [13:43] What does “status jobname” print? What appears in syslog when you run “start jobname”? [13:44] status: stop/waiting, start gives: start/running, process 2079 [13:45] anymous: please pastebin your current job file [13:45] not familiar with pastebin :-( [13:46] There probably should be no process ID if there’s no main process. [13:46] And there shouldn’t be a main process in your job. [13:46] right, theres no process running after the mount [13:47] but i think it's similair to rcS, you can't run "stop rcS" [13:47] No, more like apport [13:48] http://lmgtfy.com/?q=pastebin [13:48] ok, when I do "stop apport" it also gives: stop: Unknown instance: [13:49] mmbiebl: thanks ;) [13:49] That’s because you have apport disabled. The structure of the job should be similar nevertheless. [13:51] http://pastebin.com/ZfP8mSAu [13:52] Replace ‘script’ with ‘pre-start script’ [13:52] You don’t want a main process for that job. [13:53] Also, there’s a space between ‘runlevel’ and its parameter. [13:54] * anymous is correcting [14:05] http://pastebin.com/nxQcu7Vh but still ... status: stop/waiting [14:06] when you enable apport, its status is running after boot? [14:07] Yes [14:07] without a process? [14:08] Yes [15:02] 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] 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] i am using a console-less machine and it fails to start everything [17:58] after awhile i can start the network by hand and run "init 2" [17:58] but this is not ideal [18:09] has "initctl events" been remove to trace upstart events? [18:09] ergmh, sprinkle the last statement with some grammar, please.. [18:42] heh [18:45] BLZbubba: w/r/t logging, no there is not [21:36] 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