| === robbiew1 is now known as robbiew | ||
| ion | jhunt: FWIW, my desktop system booted fine with Upstart from https://launchpad.net/~jamesodhunt/+archive/upstart-testing | 14:34 |
|---|---|---|
| jhunt | ion: awesome, thanks for testing! | 14:34 |
| jhunt | ion: I'll be updating the ppa in the next few days with the visualisation feature (just finishing off now) so look out for more of an announcement then... | 14:36 |
| ion | Alright, i’ll notice it at the latest when running safe-upgrade. :-) | 14:37 |
| ion | How to use user jobs, btw? I didn’t notice mention of them in init(5). | 14:37 |
| ion | (Might as well look at the source.) | 14:39 |
| jhunt | The man page still needs to be updated for sessions, chroot, etc. This will come in the next few days... | 14:39 |
| jhunt | ion: feel free :) | 14:39 |
| ion | Note to self: talk to Keybuk about the method Erlang uses to elegantly and robustly implement runtime code upgrades with passing state to new versions, along with some rough ideas of how to implement the equivalent in C. | 14:41 |
| Zed` | can someone point me to some example upstart scripts? I need to start a shell script on startup and run a different one on shutdown - my google foo is failing me and I am the worst scritper on the planet | 18:16 |
| Keybuk | there is no such thing as Upstart scripts | 18:49 |
| Keybuk | the code within the script..end script block is Shell | 18:49 |
| Zed` | hrm, I have some shell scripts that a user will maintain - so I need to call a script - not maintain the script code in upstart format - that make sense? | 18:51 |
| Keybuk | sure | 19:11 |
| Keybuk | so use exec | 19:11 |
| Zed` | that much is obvious - what is not obvious is how /exactly/ to do that - hence the request for some examples | 19:26 |
| Zed` | not obvious to me* | 19:26 |
| Keybuk | Zed`: did you read the manpages? | 19:44 |
| Zed` | and the web site and google and scores of the files in /etc/init | 19:44 |
| Keybuk | and it's still not obvious? | 19:45 |
| Zed` | correct | 19:46 |
| Keybuk | well, if you've read all the files in /etc/init\ | 19:46 |
| Keybuk | then you've read all the examples | 19:46 |
| Zed` | none of them do what I want | 19:46 |
| Keybuk | are you sure? | 19:46 |
| Keybuk | perhaps they all do what you want, and you can't recognise that? | 19:46 |
| Zed` | that is a distinct possibility | 19:47 |
| Keybuk | /etc/init/failsafe-x.conf | 19:47 |
| Keybuk | for example runs a shell script on a given event (gdm being stopped with a bad exit status) | 19:47 |
| JanC | if a user needs to be able to change a script that will be run as root, you should probably give them root access... ;) | 20:04 |
| Keybuk | if a user can change a script that will be run as root, you *have* given them root access ;-) | 20:06 |
| JanC | maybe Zed` should explain what exactly they need... | 20:08 |
| Zed` | they are not root but they are /trusted/ | 20:08 |
| Zed` | and I just need to startup teracatta on boot and make sure it is shut down cleanonly on shutdown or restart | 20:09 |
| Keybuk | almost every single .conf file in /etc/init does that | 20:09 |
| Zed` | You must have missed the part where I said I don't grok the scripts | 20:10 |
| Keybuk | no, I did | 20:10 |
| Keybuk | I just don't think there' | 20:10 |
| Keybuk | s any way I can help you | 20:10 |
| Keybuk | if you don't understand shell, that's probably a good place to start | 20:11 |
| JanC | Zed`: do you mean the scripts that your users write or the upstart jobs? | 20:14 |
| Zed` | perhaps if I put up a pastebin you could tell me if I have it right? | 20:14 |
| Zed` | JanC: upstart | 20:14 |
| JanC | well, those aren't called "scripts" but "job configurations" normally (but they can contain shell scripts or run them) | 20:16 |
| JanC | and putting you job description on a pastebin might be useful, but we might need more info still... | 20:19 |
| Zed` | http://zed.pastebin.com/XqbSfpEz | 20:20 |
| Zed` | these jobs run automatically simply because they are in /etc/init/ ? | 20:23 |
| JanC | that will start the script once the filesystem is up | 20:24 |
| Zed` | indeed | 20:25 |
| JanC | the job configurations don't "run", but they describe when jobs have to run or have to be stopped | 20:25 |
| Zed` | I get that :) | 20:25 |
| Zed` | sorry if my momenclatures are lacking | 20:25 |
| JanC | and all *.conf files in that directory are read | 20:26 |
| Zed` | question is: is that the best way do do what I want | 20:26 |
| JanC | well, you say your users can change that script? | 20:26 |
| Zed` | only one user that is trusted | 20:26 |
| JanC | you do know that you give that user root access that way? | 20:27 |
| Zed` | I understand the implications | 20:27 |
| Zed` | they are the only user of the box | 20:27 |
| JanC | so, doesn't it do what you need? | 20:27 |
| Zed` | what I pasted? | 20:28 |
| JanC | yes | 20:28 |
| * Zed` laughs | 20:29 | |
| Zed` | that is what I am seekign an opinion on | 20:29 |
| Zed` | seeking* | 20:29 |
| JanC | eh? | 20:29 |
| Zed` | It seems to me that what I pasted will do what I need - however I am not qualified to know if it is correct - that is why I asked | 20:29 |
| JanC | it's easier to try, it might work, but that depends on what the script does, and as you don't control what happens in it, you're at the mercy of your user... | 20:30 |
| * Zed` sighs | 20:30 | |
| Zed` | I already explained that I am not worried about that | 20:30 |
| Zed` | the box exists for the user to run this script | 20:30 |
| Zed` | I know you are trying to help me help myuself and that is laudable and all | 20:31 |
| Zed` | I just have a simpel question: given the usecase I have explaied is what I pasted correct | 20:31 |
| Zed` | for example | 20:31 |
| Zed` | might I use a better/differet start on command | 20:31 |
| Zed` | if I could down the box indiscriminately I could test it on the blind | 20:33 |
| JanC | you don't understand, whether the job description works or not depends on such things as the script not starting anything that forks and returns to the script immediately | 20:33 |
| Zed` | but I can't | 20:33 |
| JanC | and whether "start on filesystem" is the best depends on what is going to be run (what it needs etc.) | 20:34 |
| Zed` | are there docs start ? | 20:35 |
| JanC | ? | 20:35 |
| Zed` | I don't know the difference between 'start on filesystem' and 'start on startup' for example | 20:36 |
| Zed` | or of there are other start on parameters I can use | 20:36 |
| JanC | both have manpages | 20:36 |
| Zed` | start does? | 20:37 |
| JanC | no, both events, 'start' is documenten in init(5) | 20:37 |
| Zed` | thanks much for the help - you are right, my shortcutting through the process is a mistake | 20:51 |
| Zed` | JanC: Keybuk thanks again | 20:51 |
| Delemas | I'm trying to convert an old style init.d script to upstart. It nicely hangs on initctl start service and initctl stop service. What did I do wrong? http://pastebin.com/eaxunfHj | 21:41 |
| ion | You probably told Upstart to expect a certain behavior wrt. forking from the main process and the process behaved differently. The fork tracking code in the current release is easy to confuse with an incorrect ‘expect’ stanza. A future release will fix that. If initctl status jobname prints a PID which doesn’t actually exist, that’s what’s going on. Either reboot or use the nasty kluge at http://heh.fi/tmp/workaround-upstart-snafu | 21:45 |
| ion | (‘sudo ./workaround-upstart-snafu 12345’ where 12345 is the pid reported by ‘status jobname’). | 21:45 |
| ion | If you’re not absolutely sure of how the main process daemonizes it’s better not to use ‘expect’ and tell the main process not to daemonize at all for now. | 21:46 |
| Delemas | The script is a bit weird in that it sometimes will just exit and other times it will daemonize and we want to respawn it if it dies in that case.... | 21:47 |
| Delemas | I get this from status: bmc-watchdog stop/killed, process 20574 | 21:49 |
| Delemas | hmm that ruby script certainly did something. After running it service bmc-watchdog start always gives: start: Unknown job: bmc-watchdog | 21:59 |
| ion | There’s probably a parse error in the job definition. Look at syslog for the error message. | 22:00 |
| Delemas | heh brilliant I was tailing /var/log/debug and the output was in /var/log/syslog... One of those days... | 22:04 |
| Delemas | Thanks for the help btw... | 22:04 |
| === soren_ is now known as soren | ||
| Delemas | Cool it works :) ttyl | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!