[03:22] Hello [03:24] 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:25] When I reboot, the configuration gone again and I have to manually do initctl reload-configuration again. [03:25] The startup condition I have in my file is : start on startup [03:25] And I am on Upstart 0.6.5 that is shipped with centos 6.2 [03:26] Any help/pointers is appreciated. [03:40] anyone? [04:04] anyone? [14:57] jodh: file bridge - i pulled the updates /foo.txt now works, but creating a subdir and touching a file in it doesn't. [14:58] xnox: ? certainly should do. One sec... [14:58] 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:59] xnox: I'm testing the latest code now using your example and it wfm. [15:00] 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:01] jodh: let me clear stale objects and do a clean compile. [15:02] 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] xnox: ok. [15:03] 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] but then this event will be emitted: every time we do any reexec, every time that jobfile is edited (multiple events emitted) [15:04] jodh: dpkg upgrade writes new files. [15:04] (include job files) [15:04] jodh: my understanding that in practice "start on file FPATH=/something" will all be tasks & not long running daemons with expect/respawn. [15:05] and thus the point is that we do not want to automatically start them, only when something happens. [15:05] xnox: maybe, but we can't enforce that. [15:05] true. I guess we can wait for people to use it and complain to us if stale files are a problem. [15:05] and if stale files are a problem we should point them to use XDG_RUNTIME_DIR instead, to avoid having stale file problem ;-) [15:06] 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:07] jodh: feature creep, that is a sound approach we can take, if requested to differentiate. [15:09] xnox: indeed :) [15:12] 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:21] all works fine \o/ merging. [15:21] * xnox had a syntax error in one of the conf files. [15:22] btw [15:22] the file bridge [15:22] xnox: thanks! :) [15:22] *love it* [15:23] SpamapS: ;-) you had me on the edge with the first two lines ;-) but all is good after last one. [15:23] 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:24] well.. [15:25] 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] also, what I'd really love would be 'reload on' :) [15:28] 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:29] SpamapS: is there a bug for 'reload on'? [15:34] jodh: no, but let me file that [15:34] SpamapS: thanks!! [15:34] btw if you're looking for a bug to work on.. https://bugs.launchpad.net/upstart/+bug/406397 [15:35] ... 58 affected... [15:37] SpamapS: yeah - we haven't forgotten about that one - honest! :) [15:39] jodh: its about every 10 days we get a new "I have a pid stuck..." person in here. [15:43] 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:46] we also have a lot of "It doesn't restart" and the pids in ps and status do not match. [15:49] jodh: thats a lot more complicated than 'initctl forget job-foo' [15:49] jodh: or, following exit's instead of forks (my preference.. ;)