[00:03] <stgraber> and success! Had to do quite a few more changes in nih-dbus-tool to get it to generate the right code and still have its tests pass, but it looks good now and my upstart branch builds and passes its tests!
[04:38] <ryanf> is it normal behavior for upstart to assume your process has died if you send it a USR1 signal?
[04:38] <ryanf> and if so, how can I tell it not to assume that?
[04:38] <ryanf> ideally I'd like to be able to send that signal to a process that upstart is watching without upstart itself noticing or caring
[04:38] <ryanf> it won't result in the process terminating
[05:01] <SpamapS> ryanf: no it won't assume your process has died on USR1
[05:01] <SpamapS> ryanf: upstart is ptracing looking for an exit of some kind.
[05:02] <SpamapS> ryanf: or if you havn't used 'expect fork' then it is just waitpid() on the process, which will only return if the process exits.
[05:08] <ryanf> SpamapS: that's really weird then
[05:08] <ryanf> SpamapS: what I'm getting is stuff like
[05:08] <ryanf> [170555.273477] init: sidekiq (0) main process (29388) killed by USR1 signal
[05:08] <ryanf> in the syslog
[05:08] <ryanf> and then it's marked as stopped
[05:08] <ryanf> but I can see with ps that the process is still running
[05:10] <ryanf> (I am not using expect fork btw)
[05:11] <SpamapS> ryanf: thats really odd, that message is only printed when libnih claims the child process was killed or core dumped
[05:15] <ryanf> let me double-check that
[05:15] <ryanf> oh, I see! in reality I am an idiot
[05:16] <SpamapS> ryanf: the process does exit doesn't it?
[05:16] <ryanf> yes. the twist is that there are two processes
[05:16] <ryanf> initctl lists the pid for start-stop-daemon
[05:16] <ryanf> and I was assuming that was the pid for the process started by start-stop-daemon
[05:16] <SpamapS> waitid() will only return that state if the process is literally *killed* by that signal
[05:16] <ryanf> so I was sending USR1 to start-stop-daemon, thereby killing it
[05:16] <stgraber> expect fork instead of expect daemon?
[05:17] <SpamapS> ryanf: you may not be calling start-stop-daemon right then. It should be exec'ing your process, not staying around and forking
[05:17] <stgraber> though having an upstart job use start-stop-daemon sounds pretty weird, considering upstart is doing pretty much everything start-stop-daemon was designed to do :)
[05:17] <ryanf> apparently it's the recommended way to create a pidfile for the process
[05:18] <ryanf> although come to think of it, I don't need the pidfile anymore, so maybe I should just stop using it
[05:18] <stgraber> right, you don't need a pidfile as long as upstart can figure out what your final pid is and track it
[05:20] <SpamapS> ryanf: why are you making a pidfile?
[05:20] <SpamapS> ugh, lag
[05:20] <SpamapS> as I'm hitting enter my IRC client catches up from 2 minutes ago
[05:20] <ryanf> I needed one before because I was trying to integrate with the tools that come with this software
[05:20] <ryanf> which want a pidfile
[05:20] <ryanf> but as soon as I get my own script doing the USR1 thing correctly, I have no reason to use those tools
[05:32] <ryanf> back to using a pidfile, because otherwise I don't have a way to get the pid to send USR1 to it -- semi-long story
[05:32] <ryanf> thanks a lot for pointing out my false assumptions about what was going on before though
[05:41] <ryanf> got it working completely now. thanks again.
[10:48] <jodh> xnox: your changes to https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions#Configuration_Files_for_User_Jobs are still ambiguous. Now that you've removed the table, it is not clear what happens if an override file exists earlier in the search path *and* in the current search directory. So if /etc/xdg/upstart/foo.override, ~/.config/upstart/foo.override and ~/.config/upstart/foo.conf exist, which .override applies? Can
[10:48] <jodh> you clarify this in the spec please.
[10:49] <xnox> jodh: The first one only applies.
[10:49] <jodh> xnox: also, the table would have helped a lot with writing the tests for this part of the feature I think as we need full coverage :)
[10:49] <xnox> jodh: ok, I will.
[10:49] <xnox> jodh: not really, cause by default there are 3 "system dirs" and 2 "user dirs"
[10:50] <xnox> jodh: and none of them have anything special about them. It's just a priority ordered list of conf sources.
[10:50] <jodh> xnox: I'm not saying we need to test every possible combination of those 5 directories, but we need representative tests that cover atleast 2 directories with .conf and .override in each to prove the behaviour.
[10:51] <xnox> ack.
[10:58] <xnox> jodh: I thought the test needs 3 directories and do a matrix test of all possible combinations of foo.conf & foo.override existance across all three directories.
[10:58] <xnox> It is a little overkill, but guarantees coverage.
[11:03] <xnox> jodh: updated the spec again. Please re-check for ambiguity.
[11:16] <jodh> xnox: works for me. Your update LGTM.
[11:17] <xnox> thanks.
[11:17] <jodh> xnox: I think all these on-list discussions are slowly drawing out some of the implicit assumptions we've all had up to now :)
[11:24] <xnox> =))))) yeah, the "OMG, but I thought it will do this instead" is not we want =)
[11:26] <jodh> xnox: right ;D
[11:36] <xnox> jodh: well. I now think to not change --confdir behaviour. And even in the Session Upstart to continue the same --confdir semantics (specify N times and only the Nth will be loaded)
[13:18] <xnox> jodh: while system init has conf_sources which is a NihList, the session init only has a string conf_path.
[13:19] <xnox> Does this imply that while system init supports on api level multiple conf sources, the session init doesn't?
[13:19] <xnox> Or am I misinterpreting system init & it actually also does not support multiple conf sources?
[14:35] <stgraber> jodh: hey there. Do you think you'll have time to look at my libnih merge proposal today?
[14:35] <stgraber> jodh: and thanks for the comment on the prctl branch, I'll try to add some autoconf magic around that block
[14:44] <jodh> stgraber: probably not I'm afraid - currently in the middle of putting a release together.
[14:44] <jodh> stgraber: thanks.
[14:50] <xnox> jodh: does that mean that I should clean up the autopkg merge?!
[14:51] <jodh> xnox: I'm only doing an upstream release today, but if you want to get the DEP-8 bits ready for Monday that'd be great.
[14:52] <xnox> jodh: ok. I am writting XDG config dir parser for upstart now & I have installer bug to look into. Hopefully, all will be done by Monday.
[14:53] <jodh> xnox: cool
[22:40] <ajp> trying to make my new script run on upstart, im new to upstart, where should I start?
[22:44] <JanC> ajp: probably the cookbook, see /topic
[22:44] <JanC> http://upstart.ubuntu.com/cookbook/
[22:45] <JanC> and of course the manpages  ;)
[22:57] <ajp> instead of using upstart, is it wise to add my script to @reboot in crontab? 
[22:58] <xnox> ajp: no. because you can't stop/restart/respawn @reboot entries.
[22:58] <xnox> ajp: or let users/admins temporary override some options in the job with an override file.
[22:58] <ajp> xnox: it's a script that monitors a folder for new files, compresses and moves them. I'm the only user. I just need the script to start at boot
[22:59] <xnox> ajp: I recommend you to create a logrotate snippet in /etc/logrotate.d/
[22:59] <ajp> not sure what that is
[23:00] <xnox> ajp: logrotate is a daemon that does: monitoring of files or logs, re-compresses them and keeps archived copies for a defined period of time.
[23:01] <ajp> I have the script done and it works, i just want it to run at boot so i dont have to launch it every time
[23:01] <xnox> ajp: e.g. it's the daemon that creates, keeps and cleans up all the /var/log/*.gz files.
[23:01] <ajp> the files im "compressing" are PDFs and it uses ghostscript to make them smaller, not actually compressing them
[23:01] <xnox> ah, I see.
[23:02] <ajp> :D
[23:02] <xnox> ajp: @reboot should be fine, an upstart job as well.
[23:02] <ajp> both
[23:02] <ajp> ?
[23:02] <ajp> or just 1
[23:02]  * xnox thinks with enough twiddling you can ask logrotate to use a custom "recompressor" command and use logrotate facilities for the rest.
[23:02] <ajp> i'm thinking the @reboot sounds much easier to accomplish
[23:03] <xnox> ajp: just one of the above is enough =)
[23:03] <ajp> xnox: thanks man, imma try the @reboot and see
[23:13] <ajp> so i tried the @reboot, didnt work
[23:13] <ajp> looks like imma learn upstart
[23:13] <ajp> xnox: do I only have to modify one file to add it to upstart?
[23:14] <xnox> yes.
[23:14] <ajp> /etc/init?
[23:15] <ajp> xnox: which file am i editing?
[23:15] <ajp> xnox: sorry if im pestering
[23:17] <xnox> /etc/init.d/my-cool-recompressor.conf
[23:17] <xnox> bah.
[23:17] <xnox> wrong.
[23:17] <xnox> /etc/init/my-cool-recompressor.conf
[23:18] <ajp> ok i created the file
[23:18] <ajp> but i named it MontiorScannedPDFs.conf
[23:25] <ajp> xnox: how does this look? http://pastebin.com/DVhstVqa
[23:27] <xnox> ajp: remove stop on, change start on to be
[23:27] <xnox> "start on filesystem"
[23:27] <xnox> (no need for explicit stop, as your job will be killed on shutdown anyway)
[23:28] <ajp> ok
[23:28] <ajp> so is this ready to go now
[23:28] <ajp> ?
[23:28] <xnox> yeah.
[23:28] <ajp> cool, im gunna try it. brb
[23:31] <ajp> so I start it by typing$ service MonitorScannedPDFs start   ???
[23:31] <ajp> or should i just reboot
[23:31] <xnox> either should work.
[23:31] <ajp> when i did the first one it says: http://pastebin.com/DVhstVqa
[23:32] <ajp> oops
[23:32] <ajp> start: Rejected send message, 1 matched rules; type="method_call", sender=":1.3" (uid=1000 pid=1696 comm="start MonitorScannedPDFs ") interface="com.ubuntu.Upstart0_6.Job" member="Start" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init")
[23:32] <xnox> sudo ?
[23:32] <ajp> i did
[23:32] <ajp> wait i didnt
[23:32] <ajp> lol
[23:33] <ajp> but now it says: start: Rejected send message, 1 matched rules; type="method_call", sender=":1.3" (uid=1000 pid=1696 comm="start MonitorScannedPDFs ") interface="com.ubuntu.Upstart0_6.Job" member="Start" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init")
[23:33] <ajp> sry
[23:33] <ajp> start: Job failed to start
[23:34] <ajp> xnox: this is what I have now: http://pastebin.com/zUjJ9G8c
[23:34] <ajp> do I need the . in front of the script path?
[23:35] <ajp> oh wait, fixed it. I had to add sudo in front of script path
[23:36] <ajp> now for testing
[23:36] <xnox> ajp: you can use setuid
[23:36] <ajp> explain
[23:36] <xnox> ajp: http://upstart.ubuntu.com/cookbook/#setuid
[23:36] <xnox> to run as your username.
[23:37] <ajp> oic
[23:39] <ajp> its running but the script isnt doing its job
[23:39] <ajp> although when i run the script by itself it works
[23:39] <ajp> not sure what's wrong here