| sgfault | Hello | 03:22 |
|---|---|---|
| sgfault | I need some help with setting up my job on centos 6.2 64 bit. Here's the problem, when I reboot the system and do initctl list, I don't see my custom job in the list, but I have to do initctl reload-configuration and then initctl list shows the job. | 03:24 |
| sgfault | When I reboot, the configuration gone again and I have to manually do initctl reload-configuration again. | 03:25 |
| sgfault | The startup condition I have in my file is : start on startup | 03:25 |
| sgfault | And I am on Upstart 0.6.5 that is shipped with centos 6.2 | 03:25 |
| sgfault | Any help/pointers is appreciated. | 03:26 |
| sgfault | anyone? | 03:40 |
| sgfault | anyone? | 04:04 |
| xnox | jodh: file bridge - i pulled the updates /foo.txt now works, but creating a subdir and touching a file in it doesn't. | 14:57 |
| jodh | xnox: ? certainly should do. One sec... | 14:58 |
| xnox | also I disagree on emitting events for existing files, for example opening and closing a .conf file causes the job to be reloaded and the bridge re-emits created events, when imho it shouldn't. | 14:58 |
| jodh | xnox: I'm testing the latest code now using your example and it wfm. | 14:59 |
| xnox | can we not emit events, and instead ask people to do 'start on runlevel[2345] or file FPATH="/foo" FEVENT=create', but it will be their job to check if /foo exists in pre-start and abort starting for example. | 15:00 |
| xnox | jodh: let me clear stale objects and do a clean compile. | 15:01 |
| jodh | xnox: the problem is, if we don't emit the event for existing files, this will be highly non-intuitive since a job that specifies 'start on file FPATH=/something' will never start even if /something *does* exist. | 15:02 |
| jodh | xnox: ok. | 15:02 |
| jodh | xnox: but rewriting a job file is not going to be a normal operation, unless you happen to be writing a new job and then you would want the event emitted again surely? | 15:03 |
| xnox | but then this event will be emitted: every time we do any reexec, every time that jobfile is edited (multiple events emitted) | 15:03 |
| xnox | jodh: dpkg upgrade writes new files. | 15:04 |
| xnox | (include job files) | 15:04 |
| xnox | jodh: my understanding that in practice "start on file FPATH=/something" will all be tasks & not long running daemons with expect/respawn. | 15:04 |
| xnox | and thus the point is that we do not want to automatically start them, only when something happens. | 15:05 |
| jodh | xnox: maybe, but we can't enforce that. | 15:05 |
| xnox | true. I guess we can wait for people to use it and complain to us if stale files are a problem. | 15:05 |
| xnox | and if stale files are a problem we should point them to use XDG_RUNTIME_DIR instead, to avoid having stale file problem ;-) | 15:05 |
| jodh | xnox: maybe an alternative is to support 'FEVENT=exists' so we'd only emit the event in that scenario. If FEVENT is not specified, we would only emit on (an actual)create, modify, or delete. | 15:06 |
| xnox | jodh: feature creep, that is a sound approach we can take, if requested to differentiate. | 15:07 |
| jodh | xnox: indeed :) | 15:09 |
| jodh | xnox: the re-exec case is indeed problematic. I think for now we'll need to rely on the job in question to detect that it's already processed "file". Thankfully, services like whoopsie will DTRT I believe. | 15:12 |
| xnox | all works fine \o/ merging. | 15:21 |
| * xnox had a syntax error in one of the conf files. | 15:21 | |
| SpamapS | btw | 15:22 |
| SpamapS | the file bridge | 15:22 |
| jodh | xnox: thanks! :) | 15:22 |
| SpamapS | *love it* | 15:22 |
| xnox | SpamapS: ;-) you had me on the edge with the first two lines ;-) but all is good after last one. | 15:23 |
| jodh | SpamapS: hope it's useful. There are certainly enhancements we can make. I wonder if the ability for a job to specify 'single-shot' mode would be useful as currently (as the man page states), it's very much 'multi-shot'. | 15:23 |
| SpamapS | well.. | 15:24 |
| SpamapS | I like the idea of the system abstracting away the details of inotify (which is, I assume, what it is intended to do). | 15:25 |
| SpamapS | also, what I'd really love would be 'reload on' :) | 15:25 |
| jodh | SpamapS: yes - I didn't call it upstart-inotify-bridge for that reason too in case we decide to change the implementation (and I would like to! :-) | 15:28 |
| jodh | SpamapS: is there a bug for 'reload on'? | 15:29 |
| SpamapS | jodh: no, but let me file that | 15:34 |
| jodh | SpamapS: thanks!! | 15:34 |
| SpamapS | btw if you're looking for a bug to work on.. https://bugs.launchpad.net/upstart/+bug/406397 | 15:34 |
| SpamapS | ... 58 affected... | 15:35 |
| jodh | SpamapS: yeah - we haven't forgotten about that one - honest! :) | 15:37 |
| SpamapS | jodh: its about every 10 days we get a new "I have a pid stuck..." person in here. | 15:39 |
| jodh | SpamapS: I appreciate this isn't ideal, but maybe they could use a container to develop the jobs in? Or if the jobs don't need to run as root, use the Upstart 1.7 Session Init as logout/login is quicker than reboot ;) | 15:43 |
| xnox | we also have a lot of "It doesn't restart" and the pids in ps and status do not match. | 15:46 |
| SpamapS | jodh: thats a lot more complicated than 'initctl forget job-foo' | 15:49 |
| SpamapS | jodh: or, following exit's instead of forks (my preference.. ;) | 15:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!