[00:03] 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] is it normal behavior for upstart to assume your process has died if you send it a USR1 signal? [04:38] and if so, how can I tell it not to assume that? [04:38] 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] it won't result in the process terminating [05:01] ryanf: no it won't assume your process has died on USR1 [05:01] ryanf: upstart is ptracing looking for an exit of some kind. [05:02] 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] SpamapS: that's really weird then [05:08] SpamapS: what I'm getting is stuff like [05:08] [170555.273477] init: sidekiq (0) main process (29388) killed by USR1 signal [05:08] in the syslog [05:08] and then it's marked as stopped [05:08] but I can see with ps that the process is still running [05:10] (I am not using expect fork btw) [05:11] ryanf: thats really odd, that message is only printed when libnih claims the child process was killed or core dumped [05:15] let me double-check that [05:15] oh, I see! in reality I am an idiot [05:16] ryanf: the process does exit doesn't it? [05:16] yes. the twist is that there are two processes [05:16] initctl lists the pid for start-stop-daemon [05:16] and I was assuming that was the pid for the process started by start-stop-daemon [05:16] waitid() will only return that state if the process is literally *killed* by that signal [05:16] so I was sending USR1 to start-stop-daemon, thereby killing it [05:16] expect fork instead of expect daemon? [05:17] 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] 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] apparently it's the recommended way to create a pidfile for the process [05:18] although come to think of it, I don't need the pidfile anymore, so maybe I should just stop using it [05:18] right, you don't need a pidfile as long as upstart can figure out what your final pid is and track it [05:20] ryanf: why are you making a pidfile? [05:20] ugh, lag [05:20] as I'm hitting enter my IRC client catches up from 2 minutes ago [05:20] I needed one before because I was trying to integrate with the tools that come with this software [05:20] which want a pidfile [05:20] but as soon as I get my own script doing the USR1 thing correctly, I have no reason to use those tools [05:32] 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] thanks a lot for pointing out my false assumptions about what was going on before though [05:41] got it working completely now. thanks again. [10:48] 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] you clarify this in the spec please. [10:49] jodh: The first one only applies. [10:49] 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] jodh: ok, I will. [10:49] jodh: not really, cause by default there are 3 "system dirs" and 2 "user dirs" [10:50] jodh: and none of them have anything special about them. It's just a priority ordered list of conf sources. [10:50] 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] ack. [10:58] 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] It is a little overkill, but guarantees coverage. [11:03] jodh: updated the spec again. Please re-check for ambiguity. [11:16] xnox: works for me. Your update LGTM. [11:17] thanks. [11:17] 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] =))))) yeah, the "OMG, but I thought it will do this instead" is not we want =) [11:26] xnox: right ;D [11:36] 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] jodh: while system init has conf_sources which is a NihList, the session init only has a string conf_path. [13:19] Does this imply that while system init supports on api level multiple conf sources, the session init doesn't? [13:19] Or am I misinterpreting system init & it actually also does not support multiple conf sources? === soren_ is now known as soren [14:35] jodh: hey there. Do you think you'll have time to look at my libnih merge proposal today? [14:35] jodh: and thanks for the comment on the prctl branch, I'll try to add some autoconf magic around that block [14:44] stgraber: probably not I'm afraid - currently in the middle of putting a release together. [14:44] stgraber: thanks. [14:50] jodh: does that mean that I should clean up the autopkg merge?! [14:51] 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] 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] xnox: cool === carif_ is now known as carif [22:40] trying to make my new script run on upstart, im new to upstart, where should I start? [22:44] ajp: probably the cookbook, see /topic [22:44] http://upstart.ubuntu.com/cookbook/ [22:45] and of course the manpages ;) [22:57] instead of using upstart, is it wise to add my script to @reboot in crontab? [22:58] ajp: no. because you can't stop/restart/respawn @reboot entries. [22:58] ajp: or let users/admins temporary override some options in the job with an override file. [22:58] 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] ajp: I recommend you to create a logrotate snippet in /etc/logrotate.d/ [22:59] not sure what that is [23:00] 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] 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] ajp: e.g. it's the daemon that creates, keeps and cleans up all the /var/log/*.gz files. [23:01] the files im "compressing" are PDFs and it uses ghostscript to make them smaller, not actually compressing them [23:01] ah, I see. [23:02] :D [23:02] ajp: @reboot should be fine, an upstart job as well. [23:02] both [23:02] ? [23:02] 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] i'm thinking the @reboot sounds much easier to accomplish [23:03] ajp: just one of the above is enough =) [23:03] xnox: thanks man, imma try the @reboot and see [23:13] so i tried the @reboot, didnt work [23:13] looks like imma learn upstart [23:13] xnox: do I only have to modify one file to add it to upstart? [23:14] yes. [23:14] /etc/init? [23:15] xnox: which file am i editing? [23:15] xnox: sorry if im pestering [23:17] /etc/init.d/my-cool-recompressor.conf [23:17] bah. [23:17] wrong. [23:17] /etc/init/my-cool-recompressor.conf [23:18] ok i created the file [23:18] but i named it MontiorScannedPDFs.conf [23:25] xnox: how does this look? http://pastebin.com/DVhstVqa [23:27] ajp: remove stop on, change start on to be [23:27] "start on filesystem" [23:27] (no need for explicit stop, as your job will be killed on shutdown anyway) [23:28] ok [23:28] so is this ready to go now [23:28] ? [23:28] yeah. [23:28] cool, im gunna try it. brb [23:31] so I start it by typing$ service MonitorScannedPDFs start ??? [23:31] or should i just reboot [23:31] either should work. [23:31] when i did the first one it says: http://pastebin.com/DVhstVqa [23:32] oops [23:32] 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] sudo ? [23:32] i did [23:32] wait i didnt [23:32] lol [23:33] 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] sry [23:33] start: Job failed to start [23:34] xnox: this is what I have now: http://pastebin.com/zUjJ9G8c [23:34] do I need the . in front of the script path? [23:35] oh wait, fixed it. I had to add sudo in front of script path [23:36] now for testing [23:36] ajp: you can use setuid [23:36] explain [23:36] ajp: http://upstart.ubuntu.com/cookbook/#setuid [23:36] to run as your username. [23:37] oic [23:39] its running but the script isnt doing its job [23:39] although when i run the script by itself it works [23:39] not sure what's wrong here