[systemd-devel] "StandardOutput=console" don't work as expected

[Michael Chapman]

On Wed, 30 Dec 2015, Reindl Harald wrote:
> Am 30.12.2015 um 10:50 schrieb Mantas Mikulėnas:
>>  On Wed, Dec 30, 2015 at 11:46 AM, Reindl Harald <h.reindl at thelounge.net
>>  <mailto:h.reindl at thelounge.net>> wrote:
>>          Do you really have cronjobs which need to output stuff to ssh
>>          ptys?
>>
>>      i have hundrets cronjobs which are running silent and if there is
>>      something wrong then it's echo'ed which means with crond you get a
>>      mail
>>
>>      and *no* it's no option to generate a mail at your own when you
>>      design software over years which runs aboslutely silent and so you
>>      know for trigger a alter mail you just need to echo the problem in
>>      whatever class method and you get also PHP warnings for free
>>
>>      the whole point of using echo in cronjobs is that you don't need to
>>      know anything about the mail-environment, frankly even not need to
>>      have access to the MTA or sendmail binary from your script
>> 
>>
>>  Wait, so you're asking for StandardOutput=console to magically get piped
>>  to /usr/sbin/sendmail instead of actual console?
>
> can you please stop press reply-all on a mailing-list or at least remove the 
> additonal address by hand?

Standard mailing list etiquette is to reply-to-all, since there's no 
guarantee the recipient is actually subscribed to the list.

You should be able to configure your mail client to deduplicate your 
incoming mail. There is also a mailing list option available in the 
lists.freedesktop.org web interface ("Avoid duplicate copies of 
messages?").

> NO - how do you come to that weird conclusion?
>
> i just want systemd *not to touch* the stdout behavior when asked to do so - 
> it don't need to know anything about ssh ptys, just don't touch stdout
>
> i am asking for StandardOutput=console get piped to the terminal systemctl 
> was called - the rest is done by crond as all the years before

That isn't possible at the moment, and I doubt it will ever be supported. 
The service is executed by systemd, not systemctl, and there is no 
communication channel to return a stream of output from the command back 
to systemctl.

It's not entirely clear why you're converting cron jobs to systemd 
services. What specifically is wrong with simply running your commands 
directly from cron as you have always done before?

If you must involve systemd in some way, you might be able to do what you 
want with "systemd-run --scope". This will run your command as a child 
process of cron as normal, but will encapsulate the process tree in a 
systemd scope unit (so it can take advantage of systemd's resource control 
and can be killed through systemctl).

Regards,
Michael