[02:01] i know the plan is to eventually have upstart handle temporal triggers, and be able to deprecate some areas of cron. Are there any thoughts in that implementation on how to handle email output in a cron-like way? [02:01] or should temporal tasks which need to email output stay in cron? [04:09] alienth: the addition of cron has been shelved, I don't know that it is a priority for anybody committing to upstart regularly. [04:10] alienth: so yes, I'd suggest using cron for all temporal tasks [04:10] (and IMO, its not really upstart's job, even if it would be easy.. ;) [04:13] SpamapS: txh for the input :) [04:16] SpamapS, what about starting upstart tasks from cron as a way to ensure that a cron job never runs more than once simultaneously? [04:21] spladug: yeah thats a great idea [04:21] spladug: perhaps somebody should add support for that to cron :) [04:24] think that would be tricky to do in cron natively :/ [04:24] due to how it is designed [04:24] most people use wrappers to ensure it (which is what we're doing now) [04:24] upstart does seem like a handy way to address it [04:24] but the trouble with moving some stuff into upstart is that email output becomes much more obtuse [04:25] it will be easy no doubt [04:25] (compared to cron) [04:25] the event loop can have scheduled things [04:25] I'm just not a huge fan of building everything into one daemon that runs as pid 1 [04:25] as much of a "hack" as mountall is, I like that its concerns are separate from upstart's [04:26] alienth: right, to get email output, you'd need to have something like 'errors to foo@bar.com' and then have upstart assume sendmail works .. [04:27] it just becomes more and more and more code in something that *must* work [04:27] so would a wrapper script that emails output be the best bet? [04:32] I believe mailx will only send email if there is a body [04:32] or can be coaxed to do that [04:35] roger, thanks :)