[03:22] <sgfault> Hello
[03:24] <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:25] <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:26] <sgfault> Any help/pointers is appreciated.
[03:40] <sgfault> anyone?
[04:04] <sgfault> anyone?
[14:57] <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:58] <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:59] <jodh> xnox: I'm testing the latest code now using your example and it wfm.
[15:00] <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:01] <xnox> jodh: let me clear stale objects and do a clean compile.
[15:02] <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:03] <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:04] <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:05] <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:06] <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:07] <xnox> jodh: feature creep, that is a sound approach we can take, if requested to differentiate.
[15:09] <jodh> xnox: indeed :)
[15:12] <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:21] <xnox> all works fine \o/ merging.
[15:21]  * xnox had a syntax error in one of the conf files.
[15:22] <SpamapS> btw
[15:22] <SpamapS> the file bridge
[15:22] <jodh> xnox: thanks! :)
[15:22] <SpamapS> *love it*
[15:23] <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:24] <SpamapS> well..
[15:25] <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:28] <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:29] <jodh> SpamapS: is there a bug for 'reload on'?
[15:34] <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:35] <SpamapS> ... 58 affected...
[15:37] <jodh> SpamapS: yeah - we haven't forgotten about that one - honest! :)
[15:39] <SpamapS> jodh: its about every 10 days we get a new "I have a pid stuck..." person in here.
[15:43] <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:46] <xnox> we also have a lot of "It doesn't restart" and the pids in ps and status do not match.
[15:49] <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.. ;)