=== ev_ is now known as ev [20:54] Keybuk: ETA until the new, super great features are released? (Automatic logging, run as user, capabilities) [21:36] jMCg: I don't have a patch for automatic logging ;) [21:38] Keybuk: how difficult is it to achieve that everything upstart runs through exec, pre-start, post-start, etc... has it's stdout and stderr filtered to /var/log/upstart/service[:instance].log ? [21:40] That would be really helpful, when you change a config, restart, and all of sudden mysql is givin you the finger and you don't know why. [21:41] jMCg: it requires a logging service running that receives input from those file descriptors and writes to the filesystem [21:41] while coping with buffering due to read-only filesystem during boot [21:42] and deals with a filesystem being fundamentally read-only (Chromium OS, for example) [21:42] and also avoiding the problem where if that logging service dies, every single process on the system immediately SIGPIPEs [21:44] Keybuk: I suppose SMF simply requires you to run your Solaris on an Filesystem that doesn't suck... - or it logs only services which depend on milestones >= filesystem [21:45] I don't know, I haven't looked at SMF in years [21:45] And I haven't looked at it in.. hours. [22:07] Keybuk: weren't you going to include a logging daemon, cron, initd, at, udevd, a dbus daemon and an X session manager into upstart? ;-) [22:08] No X please, it's obsolete. But we could put in a kernel. [22:09] :P [22:11] JanC: a variation of "include into" that means people could pick and chose their components and defaults [22:11] upstart is not systemd after all ;) [22:13] well, I think personally you don't need cron into upstart, but a time-based service could issue events that upstart then handles [22:14] IIRC, launchd has something of that kind [22:14] which is probably what you were thinking already [22:15] JanC: I see that as the same thing [23:08] "cgroups are used to track service processes, instead of PIDs. This means that daemons cannot "escape" systemd even by double-forking." [23:09] There are problems with using cgroups like that, which is why Upstart will go with an approach based on proc connector. [23:09] I thought it used ptrace? [23:10] “will go” [23:11] jMCg: and yet systemd explicitly recommends software doesn't daemonize [23:11] man daemon on a sd system [23:11] so I guess that works well for them [23:12] Keybuk: what does upstart recommend? [23:12] "Moreover, since some of these steps interfere with process monitoring [...] of the init system is recommended not to execute them" [23:12] jMCg: Upstart recommends that if your software doesn't work with the init daemon, you file a bug on the init daemon ;) [23:13] +1 :) [23:13] well, I guess there are several ways to handle forking etc., and all have pros & cons? [23:14] the easiest is if services are well-behaving themselves ;) [23:15] Daemonizing can’t really be thought as bad behavior per se. [23:16] In fact it can used as a good indicator about when the daemon is ready. [23:16] right, but I was thinking more about starting sub-processes and then not keeping track of them [23:17] heh.. SMF has killed my "daemons" after a timeout (usually 60) seconds, when I forgot to add a '&' [23:17] sombody complained about the earlier [23:17] about that [23:17] That was me. [23:17] ;) [23:17] I've got a bug on that. [23:18] https://issues.apache.org/jira/browse/TS-755 [23:19] I said if nobody complains, I'll commit that shit. Nobody's complained in three days. I think I can commit it. [23:21] hehe, we just set a rule for the new ubuntu-be locoteam leadership council "if nobody complains within 7 days, a proposal is accepted" ;) [23:22] How long can someone complain about that rule, or is that instantly valid? [23:22] it was proposed last Monday, and will be formally accepted next Sunday ;) [23:23] On a sunday, that's unfair, people are hungover on sunday. [23:23] wh00t. I just realized, I haven't tested this shit. [23:24] Sunday evening :P [23:24] anyway [23:24] it was already accepted by everybody important today :P