Am 30.12.2015 um 11:25 schrieb 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 <[email protected] <mailto:[email protected]>> 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
on which mailing-list is that the case? be assured it's NOT standard on the majority on most it is considered rude
since there's no guarantee the recipient is actually subscribed to the list.
and how did he write to the list then?
You should be able to configure your mail client to deduplicate your incoming mail
even my server can do that and THAT is the problem - the off-list duplicate is faster and hence the message has no list headers which breaks "reply-list" in a proper mail client
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 beforeThat 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.
since "systemctl start" on the shell waits until the "oneshot" service is finished it can't be impossible that pid 1 geives back the tasks output
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?
why not read the thread start - in the first mail i wrote: "migrate cronjobs to systemd-units for using ReadOnlyDirectory and other security otpions"
PrivateTmp=yes PrivateDevices=yes NoNewPrivileges=yes CapabilityBoundingSet=CAP_KILL CAP_CHOWN CAP_FOWNER ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr ReadOnlyDirectories=/var/lib ReadOnlyDirectories=/proc ReadOnlyDirectories=/sys InaccessibleDirectories=-/boot InaccessibleDirectories=-/home InaccessibleDirectories=-/media InaccessibleDirectories=-/root InaccessibleDirectories=-/etc/ssh InaccessibleDirectories=-/run/dbus InaccessibleDirectories=-/run/lock InaccessibleDirectories=-/run/mount InaccessibleDirectories=-/run/systemd/users InaccessibleDirectories=-/run/udev InaccessibleDirectories=-/run/user
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)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
