| Omahn | What's the correct way to abort startup of an upstart job in the pre-start script? | 10:29 |
|---|---|---|
| Omahn | Ah, possibly just 'exit 1' ? | 10:30 |
| Omahn | Seems to work. :-) | 10:32 |
| ion | That’s okay for an error. For a graceful abort, run ‘stop’. | 10:49 |
| Omahn | ion: I was just going to ask about that. So, for a misconfiguration in the setup of a given daemon, detected during pre-start, I should use exit 1. If the daemon is simply disabled in the daemon, I should use 'stop' and that will prevent the 'exec' from firing. Is that correct? | 10:51 |
| Omahn | *disabled in the configuration, that should say | 10:51 |
| ion | Yep | 10:52 |
| Omahn | ion: Great, thanks. | 10:52 |
| ion | Also note that the scripts are run with -e. In some cases, exit 1 may be redundant since the shell would exit with a non-zero value anyway. | 10:52 |
| Omahn | Noted, thanks. | 10:53 |
| yarihm | hi everybody | 14:46 |
| yarihm | I'm currently trying to get a fedora 13 container working in openvz. I'm new to upstart but if I got that correctly, the jobs are defined under /etc/init/<name>.conf in a pretty straight forward way. From what I can tell (initctl list) openvz starts init properly but that in turn is only able to start one of the jobs (the one that spawns mingetty), the others are listed as 'stop/waiting'. When I try to start the stopped job | 14:55 |
| yarihm | s I get 'initctl: Job failed to start' with no place to start debugging. | 14:55 |
| Omahn | yarihm: From my limited knowledge, it's probably something in one of your script sections exiting with non-zero. Maybe try increasing the log level of upstart with 'initctl log-priority debug' and then watching the log files. (/var/log/daemon on ubuntu, not sure on Fedora) | 15:00 |
| yarihm | Omahn, actually I tried that, too :) Let me try again, but I think initctl fails to log anything even though I started the syslog daemon | 15:01 |
| yarihm | Let me give it another shot | 15:01 |
| yarihm | ok, it doesn't log much actually, but I tried it with a test-job and that seems to be working | 15:05 |
| yarihm | I wrote a task with a pre-start script that touches a file in /tmp and a script that touches a different file in /tmp. when starting that job, initctl outputs | 15:09 |
| yarihm | [root@backend99 init]# initctl start test2 | 15:09 |
| yarihm | test2 stop/waiting | 15:09 |
| yarihm | if I add something that doesn't detach (top) in the script, it fails. Is the expectation that the started daemon/binary detaches or not? | 15:09 |
| yarihm | also: there's no logging anywhere about why this procedure fails | 15:10 |
| ion | top probably just dies immediately due to there not being a terminal. | 15:10 |
| yarihm | ah | 15:10 |
| yarihm | I see some logging in /var/log/messages BTW | 15:11 |
| ion | Task jobs aren’t for daemons, service jobs are. | 15:11 |
| yarihm | Uh, i see some issue here anyway, the mingetty-task seems to respawn because it tries to attach to the wrong device node | 15:12 |
| ion | gettys should be services, not tasks. | 15:13 |
| yarihm | what are tasks for then? | 15:14 |
| ion | Task is something you expect to run once and then end when started. Service is something you expect to keep running indefinitely when started. | 15:14 |
| yarihm | I removed the getty thing now, it's not needed in a openvz-container anyway AFAICT | 15:15 |
| ion | E.g. a job that runs sysctl -p on startup would be a task, since it should happen once and be done. Gettys are more like daemons, so they should be services. They should additionally respawn, so you get a new getty when you log out from a session. | 15:17 |
| yarihm | mhm, makes sense | 15:18 |
| yarihm | I copied an openvz-task from an ubuntu template (trying to get fedora core 13 running), that has this section here: | 15:19 |
| yarihm | task | 15:19 |
| yarihm | pre-start script | 15:19 |
| yarihm | #mount -t devpts devpts /dev/pts | 15:19 |
| yarihm | #mount -t proc proc /proc | 15:19 |
| yarihm | if [ ! -e /etc/mtab ]; then | 15:19 |
| yarihm | cat /proc/mounts > /etc/mtab | 15:19 |
| yarihm | fi | 15:19 |
| yarihm | end script | 15:19 |
| yarihm | however, when trying to start that openvz task, I get | 15:19 |
| yarihm | init: openvz pre-start process (82) terminated with status 32 | 15:19 |
| yarihm | ... how can that be? /etc/mtab actually evaluates to true | 15:20 |
| yarihm | I mean [ -e /etc/mtab ] does | 15:20 |
| ion | Just after the pre-start script line, add: | 15:20 |
| ion | exec >/dev/something.log 2>&1 | 15:21 |
| ion | set -x | 15:21 |
| yarihm | you mean exec >/tmp/something.log I guess? | 15:21 |
| ion | /dev is a safe assumption of something writable, /tmp might not be. If you know /tmp is writable, sure. | 15:22 |
| yarihm | ah, ok :) | 15:22 |
| yarihm | well, it seems that the if statement just evaluates to 32 ... whatever, I added 'true' before end script so this works now. Now it's the main-script that fails, I'll try to debug that | 15:24 |
| ion | Curious. I don’t see how the if statement could return 32. | 15:25 |
| yarihm | yeah, me neither | 15:27 |
| yarihm | is the script running as if it were 'set -e'? | 15:27 |
| yarihm | in other words, does it terminate with the first command that returns non-zero? maybe the mount commands return 32 (but they are commented out) | 15:28 |
| ion | Yes, -e is on by default. | 15:28 |
| ion | The only things i can see failing are cat opening /proc/mounts for reading and the shell opening /etc/mtab for writing. | 15:30 |
| yarihm | well, actually since the file /etc/mtab exists that should never be an issue | 15:36 |
| yarihm | cu guys l8er | 16:08 |
| === JanC_ is now known as JanC | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!