Re: Q: systemd-timer vs cron
On Sun, 13 Mar 2022 00:07:06 +, Simon McVittie wrote:
>> These are still somewhat annoying in practice because of the log entries for
>> CRON running something pointlessly.
>
>systemd-cron gets round this by assuming that /etc/cron.d/foobar
>is redundant with a native systemd timer foobar.timer, so if
>foobar.timer exists (or is explicitly masked), systemd-cron will not run
>/etc/cron.d/foobar. I don't think this naming convention is formally
>guaranteed by Policy, but it seems to work well enough in practice.
>
>systemd-cron is a third-party implementation of the cron-daemon interface
>as a systemd generator, which outputs pairs of systemd .timer and
>.service units corresponding to cron jobs. It is not part of systemd,
>and is an alternative to running a more traditional cron-daemon (Vixie
>cron or equivalent) as a long-running systemd service.
>
>This mechanism currently only works for cron.d, and not for the grouped
>hourly/daily/weekly/monthly sets of cron jobs, which always get run
>by run-parts (unless the corresponding directory is completely empty,
>in which case the appropriate hourly/daily/weekly/monthly timer is
>automatically disabled by a ConditionDirectoryNotEmpty rule).
>
> ... https://lists.debian.org/debian-devel/2022/03/msg00211.html
Hi, I want to change this part for the Trixie cycle;
I just uploaded a new systemd-cron right now.
The needed "part" name to timer "name" translation table
has been included in the upstream repos. There will certainly a lot
a cases missing ... a smarter idea is welcomed
(the easiest on my side is to ask packages to always use
same name for /etc/cron.*/ and .timer)
To do nothing faster systemd-cron could/should be rewritten in C/C++.
> # this is dumb, but gets the job done ... for now
>PART2TIMER = {
>'apt-compat': 'apt-daily',
>'dpkg': 'dpkg-db-backup',
>'plocate': 'plocate-updatedb',
>}
systemd-cron (1.15.21-1) unstable; urgency=low
* do not use "run-parts" anymore to execute /etc/cron.{hourly|weekly|monthly}
and instead generate a .timer+.service pair by item.
Most prominent Debian packages already provide their own .timer:
apt, dpkg, man-deb, plocate ... in this case systemd-cron does nothing.
Re: Q: systemd-timer vs cron
On Wed, 2022-03-16 at 08:01 +0800, Paul Wise wrote: > On Tue, 2022-03-15 at 13:28 +, Luca Boccassi wrote: > > > Yes indeed, logs can be filtered by invocation id, eg: > > > > journalctl INVOCATION_ID=abcdefg > > That sounds useful. > > > Also to make a unit's log "private" (not stored in the system > > journal) > > LogNamespace= can be used, see: > > > > https://www.freedesktop.org/software/systemd/man/systemd.exec.html#LogNamespace= > > That sounds useful too but not for my use-case due to: > > This option is only available for system services and is not > supported for services running in per-user instances of the > service manager. > > I guess the reason for this is that it uses mount namespaces to > override the journald socket, rather than just pointing the process > at > a different socket via another mechanism. That will actually work from v251 too (as long as PrivateUsers=yes and TemporaryFileSystem=/run are also configured), with one caveat: given the journald instance is a system unit rather than a user one, a user unit won't have privileges to start it automagically. But it's very trivial to start it manually if you are configuring the user unit, since it's just a template based on the chosen namespace. Ie, for a unit with LogNamespace=foo, a 'systemctl start systemd-journald@foo.service' once at boot will do the trick. I'll see if I can make it work safely and automagically, without the manual start, before the next release, but no promises. Journal files will be stored under /[var|run]/log/journal/.foo/ and be separated from the system ones. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: Q: systemd-timer vs cron
On Tue, 2022-03-15 at 15:32 +0100, Philip Hands wrote: > Michael Biebl writes: > > > Am 15.03.22 um 03:31 schrieb Paul Wise: > > > On Mon, 2022-03-14 at 11:47 +0100, Marco d'Itri wrote: > > > > > > > Yes, this is true. These are the unit and script that I use, > > > > and I think > > > > that Debian would benefit from having something like this > > > > available in > > > > some common package. > > > ... > > > > $(systemctl status "$FAILED_UNIT" --full --lines=100) > > > > > > Unfortunately for my cron jobs I need the entire output of the > > > command > > > invocation, don't want any output from prior runs of the command > > > and > > > don't want any of the output to end up in the systemd journal. > > > > > > So I need something like StandardOutput=mail or to add some sort > > > of > > > wrapper script to each of the relevant systemd timers. > > > > I might be mistaken here, but Luca hinted at > > $MONITOR_INVOCATION_ID in his email which means one could easily > > filter > > journal output for the last failed invocation using this > > $MONITOR_INVOCATION_ID. > > Luca, is this understanding correct? > > Afaics this would cover Paul's use case > > Except for the "don't want any of the output to end up in the systemd > journal" bit. > > Cheers, Phil. See other reply to pabs w.r.t. LogNamespace=. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: Q: systemd-timer vs cron
On Tue, 2022-03-15 at 13:28 +, Luca Boccassi wrote: > Yes indeed, logs can be filtered by invocation id, eg: > > journalctl INVOCATION_ID=abcdefg That sounds useful. > Also to make a unit's log "private" (not stored in the system journal) > LogNamespace= can be used, see: > > https://www.freedesktop.org/software/systemd/man/systemd.exec.html#LogNamespace= That sounds useful too but not for my use-case due to: This option is only available for system services and is not supported for services running in per-user instances of the service manager. I guess the reason for this is that it uses mount namespaces to override the journald socket, rather than just pointing the process at a different socket via another mechanism. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Q: systemd-timer vs cron
Michael Biebl writes: > Am 15.03.22 um 03:31 schrieb Paul Wise: >> On Mon, 2022-03-14 at 11:47 +0100, Marco d'Itri wrote: >> >>> Yes, this is true. These are the unit and script that I use, and I think >>> that Debian would benefit from having something like this available in >>> some common package. >> ... >>> $(systemctl status "$FAILED_UNIT" --full --lines=100) >> >> Unfortunately for my cron jobs I need the entire output of the command >> invocation, don't want any output from prior runs of the command and >> don't want any of the output to end up in the systemd journal. >> >> So I need something like StandardOutput=mail or to add some sort of >> wrapper script to each of the relevant systemd timers. > > I might be mistaken here, but Luca hinted at > $MONITOR_INVOCATION_ID in his email which means one could easily filter > journal output for the last failed invocation using this > $MONITOR_INVOCATION_ID. > Luca, is this understanding correct? > Afaics this would cover Paul's use case Except for the "don't want any of the output to end up in the systemd journal" bit. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Q: systemd-timer vs cron
On Tue, 2022-03-15 at 09:48 +0100, Michael Biebl wrote: > Am 15.03.22 um 03:31 schrieb Paul Wise: > > On Mon, 2022-03-14 at 11:47 +0100, Marco d'Itri wrote: > > > > > Yes, this is true. These are the unit and script that I use, and I think > > > that Debian would benefit from having something like this available in > > > some common package. > > ... > > > $(systemctl status "$FAILED_UNIT" --full --lines=100) > > > > Unfortunately for my cron jobs I need the entire output of the command > > invocation, don't want any output from prior runs of the command and > > don't want any of the output to end up in the systemd journal. > > > > So I need something like StandardOutput=mail or to add some sort of > > wrapper script to each of the relevant systemd timers. > > I might be mistaken here, but Luca hinted at > $MONITOR_INVOCATION_ID in his email which means one could easily filter > journal output for the last failed invocation using this > $MONITOR_INVOCATION_ID. > Luca, is this understanding correct? > Afaics this would cover Paul's use case > > Michael > > [1] https://lists.debian.org/debian-devel/2022/03/msg00240.html Yes indeed, logs can be filtered by invocation id, eg: journalctl INVOCATION_ID=abcdefg Also to make a unit's log "private" (not stored in the system journal) LogNamespace= can be used, see: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#LogNamespace= -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: Q: systemd-timer vs cron
Am 15.03.22 um 03:31 schrieb Paul Wise: On Mon, 2022-03-14 at 11:47 +0100, Marco d'Itri wrote: Yes, this is true. These are the unit and script that I use, and I think that Debian would benefit from having something like this available in some common package. ... $(systemctl status "$FAILED_UNIT" --full --lines=100) Unfortunately for my cron jobs I need the entire output of the command invocation, don't want any output from prior runs of the command and don't want any of the output to end up in the systemd journal. So I need something like StandardOutput=mail or to add some sort of wrapper script to each of the relevant systemd timers. I might be mistaken here, but Luca hinted at $MONITOR_INVOCATION_ID in his email which means one could easily filter journal output for the last failed invocation using this $MONITOR_INVOCATION_ID. Luca, is this understanding correct? Afaics this would cover Paul's use case Michael [1] https://lists.debian.org/debian-devel/2022/03/msg00240.html OpenPGP_signature Description: OpenPGP digital signature
Re: Q: systemd-timer vs cron
On Mon, 2022-03-14 at 11:47 +0100, Marco d'Itri wrote: > Yes, this is true. These are the unit and script that I use, and I think > that Debian would benefit from having something like this available in > some common package. ... > $(systemctl status "$FAILED_UNIT" --full --lines=100) Unfortunately for my cron jobs I need the entire output of the command invocation, don't want any output from prior runs of the command and don't want any of the output to end up in the systemd journal. So I need something like StandardOutput=mail or to add some sort of wrapper script to each of the relevant systemd timers. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Q: systemd-timer vs cron
On 2022-03-13 01:07, Simon McVittie wrote: > - reserving an environment variable like SKIP_CRON_JOB_UNDER_SYSTEMD=1 > to act as a request to skip parsing this cron job on systemd systems > (it would also be set like any other environment variable when the cron > job is executed on a non-systemd system, but that should generally be > harmless, because programs are generally expected to ignore unknown > environment variables) I guess I overlooked this at first, because this sounds like a really simple solution, 3 LOC or so. It also shouldn't conflict with anything else out there.
Re: Q: systemd-timer vs cron
Am 14.03.22 um 20:43 schrieb Josh Triplett: Michael Biebl wrote: I'd agree here. user crontabs are such a niche case where systemd's own facilities don't provide a direct replacement. That said, my main point was about packages shipping cron files. As a distro we'd benefit if those shipped native systemd timers (instead or in addition). I don't think we have any packages in the archive that make direct use of user crontabs? If all packages shipped native systemd timers I could envision that at some point it would make sense to stop installing cron by default and users that need or want user crontab can just run apt install cron. Perhaps a first step would be to promote lintian's `missing-systemd-timer-for-cron-script` (https://lintian.debian.org/tags/missing-systemd-timer-for-cron-script) from "pedantic" to "warning"? If that were fixed for the majority of packages, `cron` could then become priority optional, with a release note suggesting to install it to support user crontabs. Probably a good idea, yeah. OpenPGP_signature Description: OpenPGP digital signature
Re: Q: systemd-timer vs cron
Michael Biebl wrote: > I'd agree here. user crontabs are such a niche case where systemd's > own facilities don't provide a direct replacement. > > That said, my main point was about packages shipping cron files. > > As a distro we'd benefit if those shipped native systemd timers > (instead or in addition). I don't think we have any packages in the > archive that make direct use of user crontabs? > > If all packages shipped native systemd timers I could envision that at > some point it would make sense to stop installing cron by default and > users that need or want user crontab can just run apt install cron. Perhaps a first step would be to promote lintian's `missing-systemd-timer-for-cron-script` (https://lintian.debian.org/tags/missing-systemd-timer-for-cron-script) from "pedantic" to "warning"? If that were fixed for the majority of packages, `cron` could then become priority optional, with a release note suggesting to install it to support user crontabs.
Re: Q: systemd-timer vs cron
Am 14.03.22 um 16:28 schrieb Colin Watson: On Mon, Mar 14, 2022 at 09:29:56AM +0800, Paul Wise wrote: On Sun, 2022-03-13 at 18:02 +0100, Christian Kastner wrote: I don't think that's a very constructive line of argument. As a former maintainer, it was evident that user crontabs (crontab -e) are still very popular, as are some other perhaps niche features, and I've never had the impression that anti-systemd has anything to do with it. As a systemd user who has a large user crontab I have to agree. I'd like to migrate to systemd timers, but there are a few blockers: Also systemd timers require a session to be running, so as I understand it you have to configure lingering (loginctl enable-linger) for users who want to use per-user timers I'd agree here. user crontabs are such a niche case where systemd's own facilities don't provide a direct replacement. That said, my main point was about packages shipping cron files. As a distro we'd benefit if those shipped native systemd timers (instead or in addition). I don't think we have any packages in the archive that make direct use of user crontabs? If all packages shipped native systemd timers I could envision that at some point it would make sense to stop installing cron by default and users that need or want user crontab can just run apt install cron. Regards, Michael OpenPGP_signature Description: OpenPGP digital signature
Re: Q: systemd-timer vs cron
On Mon, 2022-03-14 at 15:28 +, Colin Watson wrote:
> I'm not particularly anti-systemd - there are lots of things about it
> that I like and use. However, I'm not sure the ergonomics of it
> weighed up against user crontabs are particularly favourable.
I think we are only talking about possibly replacing cronjobs shipped
by packages with .timer units in this thread, i.e., the files in
/etc/cron.d and /etc/cron.{daily,monthly,weekly}.
Cron jobs added manually by users or system administrators are a
different problem. There is only a very small contact area: if we
replace all cron jobs with .timer units, then we might also choose to
no longer install cron by default and users would have to install it
manually.
Ansgar
Re: Q: systemd-timer vs cron
On Mon, Mar 14, 2022 at 09:29:56AM +0800, Paul Wise wrote: > On Sun, 2022-03-13 at 18:02 +0100, Christian Kastner wrote: > > I don't think that's a very constructive line of argument. As a former > > maintainer, it was evident that user crontabs (crontab -e) are still > > very popular, as are some other perhaps niche features, and I've never > > had the impression that anti-systemd has anything to do with it. > > As a systemd user who has a large user crontab I have to agree. > > I'd like to migrate to systemd timers, but there are a few blockers: Also systemd timers require a session to be running, so as I understand it you have to configure lingering (loginctl enable-linger) for users who want to use per-user timers that aren't tied to having an interactive session (surely the common case). This is frankly obscure - there's no mention of it in systemd.timer(5), and I only found out about it from the Arch wiki. I'm not particularly anti-systemd - there are lots of things about it that I like and use. However, I'm not sure the ergonomics of it weighed up against user crontabs are particularly favourable. Unlike init scripts, for instance, it usually requires noticeably more typing to write a systemd timer than a cron job. The trade-off is that you get better observability and fancier controls over when and how things run. That trade-off usually seems to be worth it for packaged cron jobs, but I have a fair few ad-hoc user cron jobs where I don't feel particularly enthusiastic about it. I'd hate to have to write the release notes entry telling people that they had to use timers rather than user crontabs! systemd-cron provides a generator so that the traditional domain-specific language for crontabs remains available, which seems like a decent approach. I haven't used it, but in general I think the crontab syntax is much stickier than the particular cron implementation. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Q: systemd-timer vs cron
On 2022-03-14 08:48, Marc Haber wrote: > On Sun, 13 Mar 2022 18:02:55 +0100, Christian Kastner >> I don't think that's a very constructive line of argument. As a former >> maintainer, it was evident that user crontabs (crontab -e) are still >> very popular, as are some other perhaps niche features, and I've never >> had the impression that anti-systemd has anything to do with it. > > That was not my intention to say. I think I could have expressed myself better as well. I read "anti-systemd" and "unmaintained", and by addressing the these arguments, I only wanted to point out how conclusions drawn from these might be questionable. I probably could have left out the part where the work stopped and what would be needed to move forward, as that is document in the respective WNPP bugs. > And I didn't want to put your maintenance work in a bad light. I didn't take it as such, actually I simply assumed you were unaware of the maintenance work. > Not being a systemd fanboi myself, for many things I prefer having > mechanisms outside of systemd, but if an alternative is unlikely to > move forward any time soon, I'd seriously consider migrating to > something that IS moving forward, and that is systemd timers. That's the way that I see it, too. cron has this bad luck that basically every Linux and BSD distribution has its own fork of Vixie cron (1993) or its successor ISC cron (2000), so there is no reasonable collaboration / sharing of work between upstreams, so most of them are mainly one-person shows. systemd has not only the benefit of being newer, but also appears to have many eyes on it. It also comes with a large number of security features that may be useful for job execution.
Re: Q: systemd-timer vs cron
On Mon, 2022-03-14 at 11:47 +0100, Marco d'Itri wrote: > On Mar 14, Paul Wise wrote: > > > AFAICT OnSuccess/OnFailure services don't recieve the output of the > > succeeding/failing service. So the mail sending service needs to dig > > around in the systemd journal. Or make the service output go to a file, > > FIFO or socket and then send that to a mail. > Yes, this is true. These are the unit and script that I use, and I think > that Debian would benefit from having something like this available in > some common package. > > I think that there is still space for cron jobs and for having a cron > package installed by default, but also that packages should seriously > consider migrating their cron jobs to timer units. From v251 (should be out soon-ish) processes spawned via OnFailure/OnSuccess will get the following env vars set automatically: $MONITOR_UNIT $MONITOR_SERVICE_RESULT $MONITOR_EXIT_CODE $MONITOR_EXIT_STATUS $MONITOR_INVOCATION_ID Besides, OnFailure/OnSuccess really should start templated units anyway, so that you get exactly one instance per invocation. So the pattern you noted with on-failure@n.service is the right thing anyway. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: Q: systemd-timer vs cron
On Mon, 14 Mar 2022 at 11:47:33 +0100, Marco d'Itri wrote: > On Mar 14, Paul Wise wrote: > > AFAICT OnSuccess/OnFailure services don't recieve the output of the > > succeeding/failing service. So the mail sending service needs to dig > > around in the systemd journal. > > Yes, this is true. These are the unit and script that I use, and I think > that Debian would benefit from having something like this available in > some common package. systemd-cron has something very similar, which it uses for the units that it generates from crontab entries. > I think that there is still space for cron jobs and for having a cron > package installed by default I'm not sure whether systemd-cron is ready to be that default yet, but it might be a good candidate for people who are interested in cron jobs to work on? (I use it myself, but I am not involved in maintaining it.) smcv
Re: Q: systemd-timer vs cron
On Mar 14, Paul Wise wrote:
> AFAICT OnSuccess/OnFailure services don't recieve the output of the
> succeeding/failing service. So the mail sending service needs to dig
> around in the systemd journal. Or make the service output go to a file,
> FIFO or socket and then send that to a mail.
Yes, this is true. These are the unit and script that I use, and I think
that Debian would benefit from having something like this available in
some common package.
I think that there is still space for cron jobs and for having a cron
package installed by default, but also that packages should seriously
consider migrating their cron jobs to timer units.
admin@rs1:~$ cat /etc/systemd/system/status-email@.service
# Add this to the unit to be monitored:
#
# [Unit]
# OnFailure=status-email@%n.service
[Unit]
Description=Status mailer unit for %i
[Service]
Type=oneshot
ExecStart=/usr/local/bin/systemd-email n...@minap.it
Environment=FAILED_UNIT=%i
Environment=HOSTNAME=%H
admin@rs1:~$ cat /usr/local/bin/systemd-email
#!/bin/sh -e
if [ "$1" ]; then
MAILTO="$1"
else
MAILTO="root"
fi
if [ -z "$FAILED_UNIT" ]; then
echo "\$FAILED_UNIT is not set!" 2>&1
exit 1
fi
fuu=$(systemctl show $FAILED_UNIT --property=User)
fuu="${fuu#User=}"
if [ "$fuu" ]; then
shortfrom="$fuu@${HOSTNAME%%.*}"
else
shortfrom="$root@${HOSTNAME%%.*}"
fi
exec /usr/sbin/sendmail -t < $FAILED_UNIT
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Auto-Submitted: auto-generated
$(systemctl status "$FAILED_UNIT" --full --lines=100)
EOF
--
ciao,
Marco
signature.asc
Description: PGP signature
Re: Q: systemd-timer vs cron
On Mon, 14 Mar 2022 09:29:56 +0800, Paul Wise wrote: >The cron feature of sending the output via email by default isn't >possible to get easily with systemd timers or systemd-cron, unless you >modify every single timer to manually send email or use systemd-cron >and have every single timer fail. This is something that has been hindering migrations since I was young: People identify one feature that is going away as vitally important to them and use that to reject the movement, even if it's an advance in sum. See NAT or DHCP for IPv6. >Having everything in one file makes them more convenient to edit. Same ;-) >Being able to implicitly share environment variables between groups of >crontab lines is more convenient. Since Lennart seems to have decided not to get rid of the EnvironmentFile setting, that can be replaced. >Figuring out if there native systemd equivalents for features I've >implemented manually, such as the lock and sleep times to ensure system >load isn't high due to running everything at once or disabling jobs >when the network isn't online. I think that the equivalent of cron.daily in systemd timers would make excessive use of start point randomization, that is going to take care of load spikes. Additionally, it will take care of load spikes in VM environments (see 07:35 when all machines begin their cron.daily simultaneously). Migrating to more randomized times of daily runs is also going to expose the case where certain cron jobs depend on each other and only work if they're executed in exact order. >Spending the time to migrate everything. Yes, that's a point. Would it be an alternative to spend time on cron and cronie patching and packaging? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Q: systemd-timer vs cron
On Sun, 13 Mar 2022 18:02:55 +0100, Christian Kastner wrote: >On 2022-03-13 11:06, Marc Haber wrote: >> The anti-systemd faction in Debian is cordially invited to step in, >> bring cron and cronie up to shape, before asking the rest of the >> Distribution to stick with essential system software that has been >> unmaintained for years. > >I don't think that's a very constructive line of argument. As a former >maintainer, it was evident that user crontabs (crontab -e) are still >very popular, as are some other perhaps niche features, and I've never >had the impression that anti-systemd has anything to do with it. That was not my intention to say. And I didn't want to put your maintenance work in a bad light. You had quite ambitioned plans and I am sad that it didn't work out. And, given our personpower problem regarding core packages, your plans are unlikely to go forward any time soon with both cron and cronie being more or less maintainerless. Not being a systemd fanboi myself, for many things I prefer having mechanisms outside of systemd, but if an alternative is unlikely to move forward any time soon, I'd seriously consider migrating to something that IS moving forward, and that is systemd timers. >And in all fairness, I did invest a lot of time maintaining it over the >years before I stepped down recently. I spent hundreds of hours alone on >converting our fork of Vixie cron from source format 1.0 to 3.0 (the >cumulative 1.0 diff spanned more than two decades of changes) so that >our fork can more easily be compared and merged with other cron forks, >such as cronie. That was very good work and I am sad to see that this work is unlikely to be done soon. >I completed that task a while ago, but then lost all motivation to >continue further. The cron daemons all originate from the early 90s. >systemd timers, being newer, just seem like a much cleaner >implementation, and thus the way forward to me. I could no longer muster >the time or energy to work on something I wasn't happy with, so I >stepped down. I fully understand. >In my opinion, the way forward for cron would be for someone to adopt >cronie, carry over any Debian patches not already included or equivalent >(there aren't too many, last time I checked), and to make cronie the new >default cron daemon. That would be very good. Sadly I am not in a position to do that myself because I lack the C skills. i surly hope that someone steps in. Thank you for caring about cron and cronie! Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Q: systemd-timer vs cron
On Mon, 2022-03-14 at 07:11 +0100, Michael Biebl wrote: > See https://lists.debian.org/debian-devel/2020/01/msg00205.html AFAICT OnSuccess/OnFailure services don't recieve the output of the succeeding/failing service. So the mail sending service needs to dig around in the systemd journal. Or make the service output go to a file, FIFO or socket and then send that to a mail. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Q: systemd-timer vs cron
Am 14.03.22 um 02:29 schrieb Paul Wise: The cron feature of sending the output via email by default isn't possible to get easily with systemd timers or systemd-cron, unless you modify every single timer to manually send email See https://lists.debian.org/debian-devel/2020/01/msg00205.html OpenPGP_signature Description: OpenPGP digital signature
Re: Q: systemd-timer vs cron
On Sun, 2022-03-13 at 18:02 +0100, Christian Kastner wrote: > I don't think that's a very constructive line of argument. As a former > maintainer, it was evident that user crontabs (crontab -e) are still > very popular, as are some other perhaps niche features, and I've never > had the impression that anti-systemd has anything to do with it. As a systemd user who has a large user crontab I have to agree. I'd like to migrate to systemd timers, but there are a few blockers: The cron feature of sending the output via email by default isn't possible to get easily with systemd timers or systemd-cron, unless you modify every single timer to manually send email or use systemd-cron and have every single timer fail. Having everything in one file makes them more convenient to edit. Being able to implicitly share environment variables between groups of crontab lines is more convenient. Figuring out if there native systemd equivalents for features I've implemented manually, such as the lock and sleep times to ensure system load isn't high due to running everything at once or disabling jobs when the network isn't online. Spending the time to migrate everything. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Q: systemd-timer vs cron
On 2022-03-13 11:06, Marc Haber wrote: > The anti-systemd faction in Debian is cordially invited to step in, > bring cron and cronie up to shape, before asking the rest of the > Distribution to stick with essential system software that has been > unmaintained for years. I don't think that's a very constructive line of argument. As a former maintainer, it was evident that user crontabs (crontab -e) are still very popular, as are some other perhaps niche features, and I've never had the impression that anti-systemd has anything to do with it. And in all fairness, I did invest a lot of time maintaining it over the years before I stepped down recently. I spent hundreds of hours alone on converting our fork of Vixie cron from source format 1.0 to 3.0 (the cumulative 1.0 diff spanned more than two decades of changes) so that our fork can more easily be compared and merged with other cron forks, such as cronie. I completed that task a while ago, but then lost all motivation to continue further. The cron daemons all originate from the early 90s. systemd timers, being newer, just seem like a much cleaner implementation, and thus the way forward to me. I could no longer muster the time or energy to work on something I wasn't happy with, so I stepped down. In my opinion, the way forward for cron would be for someone to adopt cronie, carry over any Debian patches not already included or equivalent (there aren't too many, last time I checked), and to make cronie the new default cron daemon. Best, Christian
Re: Q: systemd-timer vs cron
On Sun, Mar 13, 2022 at 11:06:46AM +0100, Marc Haber wrote: > The anti-systemd faction in Debian is cordially invited to step in, > bring cron and cronie up to shape, before asking the rest of the > Distribution to stick with essential system software that has been > unmaintained for years. And in that case, they please generate cron files from systemd timer units. Bastian -- Warp 7 -- It's a law we can live with.
Re: Q: systemd-timer vs cron
On Sun, 13 Mar 2022 08:47:27 +0100, Christian Kastner wrote: >Unless cron finds a new maintainer (#984736), I don't think either of >these are going to happen. This looks like we all should migrate over to systemd timers as soon as possible for everything, leaving the burden of keeping cron alive to those systemd-free distributions. The anti-systemd faction in Debian is cordially invited to step in, bring cron and cronie up to shape, before asking the rest of the Distribution to stick with essential system software that has been unmaintained for years. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Q: systemd-timer vs cron
On 2022-03-12 21:42, Michael Biebl wrote: > - Teach cron about systemd timers and allow cron entries to be marked > with meta data that tells cron that when run under systemd it should > skip those entries. On 2022-03-13 01:07, Simon McVittie wrote: > If there was a way to flag system cron jobs with metadata that says > "this is redundant when running under systemd", [...] > I personally think I've written those in preference order (best one first), > but it's up to the cron implementors' tastes rather than mine. Unless cron finds a new maintainer (#984736), I don't think either of these are going to happen. Best, Christian
Re: Q: systemd-timer vs cron
On Sat, 12 Mar 2022 at 14:40:32 -0500, Michael Stone wrote: > On Sat, Mar 12, 2022 at 03:19:52PM +0800, Paul Wise wrote: > > Do what apt does; make the cron job exit successfully without doing > > anything when run on systemd, move most of what is being run into a > > script or program in /usr, then call that from the timer and cron job. > > > > Alternatively, make the cron job exit successfully without doing > > anything when run on systemd, then have the timer call the cron job > > with a --run-on-systemd argument that makes it run under systemd. > > These are still somewhat annoying in practice because of the log entries for > CRON running something pointlessly. systemd-cron gets round this by assuming that /etc/cron.d/foobar is redundant with a native systemd timer foobar.timer, so if foobar.timer exists (or is explicitly masked), systemd-cron will not run /etc/cron.d/foobar. I don't think this naming convention is formally guaranteed by Policy, but it seems to work well enough in practice. systemd-cron is a third-party implementation of the cron-daemon interface as a systemd generator, which outputs pairs of systemd .timer and .service units corresponding to cron jobs. It is not part of systemd, and is an alternative to running a more traditional cron-daemon (Vixie cron or equivalent) as a long-running systemd service. This mechanism currently only works for cron.d, and not for the grouped hourly/daily/weekly/monthly sets of cron jobs, which always get run by run-parts (unless the corresponding directory is completely empty, in which case the appropriate hourly/daily/weekly/monthly timer is automatically disabled by a ConditionDirectoryNotEmpty rule). If there was a way to flag system cron jobs with metadata that says "this is redundant when running under systemd", then that would remove this redundancy for the more traditional cron-daemon setup too. That would be a feature request for traditional cron implementations (and systemd-cron) rather than a feature request for systemd. Some backwards-compatible ways that I can think of to represent that flag in crontab(5) syntax are: - reserving an environment variable like SKIP_CRON_JOB_UNDER_SYSTEMD=1 to act as a request to skip parsing this cron job on systemd systems (it would also be set like any other environment variable when the cron job is executed on a non-systemd system, but that should generally be harmless, because programs are generally expected to ignore unknown environment variables) - a magic comment, analogous to LSB "### BEGIN INIT INFO" comments (the major disadvantage of this approach is that it requires parsing comments, which always seems like a "code smell" to me) - having a single conventional way to spell not-systemd guard, parsing the shell command to see whether it includes the guard, and skipping commands that do (I don't like this aesthetically, because I feel as though the shell command should be treated as opaque, and more practically I suspect there are lots of variations of how to spell the guard: && vs. if/fi, [ -d ] vs. test -d, and so on) I personally think I've written those in preference order (best one first), but it's up to the cron implementors' tastes rather than mine. smcv
Re: Q: systemd-timer vs cron
Am 12.03.22 um 20:40 schrieb Michael Stone: On Sat, Mar 12, 2022 at 03:19:52PM +0800, Paul Wise wrote: Hideki Yamane wrote: Is there any suggestion or guideline for pacakges that contain both systemd-timer unit setting and cronjob? Don't they conflict or not Do what apt does; make the cron job exit successfully without doing anything when run on systemd, move most of what is being run into a script or program in /usr, then call that from the timer and cron job. Alternatively, make the cron job exit successfully without doing anything when run on systemd, then have the timer call the cron job with a --run-on-systemd argument that makes it run under systemd. These are still somewhat annoying in practice because of the log entries for CRON running something pointlessly. That is indeed true. I guess we have three options here: - Teach cron about systemd timers and allow cron entries to be marked with meta data that tells cron that when run under systemd it should skip those entries. - Ship native systemd timer units for all packages and no longer install cron by default - If a package is shipping a native systemd timer unit, it should drop the corresponding cron files. Those should be generated on the fly on non-systemds based on the systemd timer. OpenPGP_signature Description: OpenPGP digital signature
Re: Q: systemd-timer vs cron
Am 12.03.22 um 08:09 schrieb Andreas Metzler: On 2022-03-12 Hideki Yamane wrote: Is there any suggestion or guideline for pacakges that contain both systemd-timer unit setting and cronjob? Don't they conflict or not Hello, You want to skip running the cronjob on systems with systemd as init systems. e.g. exim's daily cronjob works like this: 1. the systemd unit runs /etc/cron.daily/exim4-base with argument systemd-timer. 2. /etc/cron.daily/exim4-base checks for a systemd setup by testing existence of /run/systemd/system. On a systemd setup the script exits immediately when executed from cron (i.e. $1!=systemd-timer). I would consider this an anti-pattern. If you have such a complex cron-daily script, I'd factor that out into a script in /usr/lib/foo and call that directly from both the cron entry and the systemd timer. It's the same kind of anti pattern like creating a .service unit containing ExecStart=/etc/init.d/foo systemd Please don't do that. If you actually have a need to call complex shell machinery to run your daemon, please factor this out into an independent script and call it from either the sysv init script or the systemd service file. systemd services should not depend on SysV init scripts and systemd timers should not depend on cron files. OpenPGP_signature Description: OpenPGP digital signature
Re: Q: systemd-timer vs cron
On Sat, Mar 12, 2022 at 03:19:52PM +0800, Paul Wise wrote: Hideki Yamane wrote: Is there any suggestion or guideline for pacakges that contain both systemd-timer unit setting and cronjob? Don't they conflict or not Do what apt does; make the cron job exit successfully without doing anything when run on systemd, move most of what is being run into a script or program in /usr, then call that from the timer and cron job. Alternatively, make the cron job exit successfully without doing anything when run on systemd, then have the timer call the cron job with a --run-on-systemd argument that makes it run under systemd. These are still somewhat annoying in practice because of the log entries for CRON running something pointlessly.
Re: Q: systemd-timer vs cron
Hideki Yamane wrote: > Is there any suggestion or guideline for pacakges that contain > both systemd-timer unit setting and cronjob? Don't they conflict > or not Do what apt does; make the cron job exit successfully without doing anything when run on systemd, move most of what is being run into a script or program in /usr, then call that from the timer and cron job. Alternatively, make the cron job exit successfully without doing anything when run on systemd, then have the timer call the cron job with a --run-on-systemd argument that makes it run under systemd. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Q: systemd-timer vs cron
On 2022-03-12 Hideki Yamane wrote: > Is there any suggestion or guideline for pacakges that contain > both systemd-timer unit setting and cronjob? Don't they conflict > or not Hello, You want to skip running the cronjob on systems with systemd as init systems. e.g. exim's daily cronjob works like this: 1. the systemd unit runs /etc/cron.daily/exim4-base with argument systemd-timer. 2. /etc/cron.daily/exim4-base checks for a systemd setup by testing existence of /run/systemd/system. On a systemd setup the script exits immediately when executed from cron (i.e. $1!=systemd-timer). If the cron script itself was trivial I would avoid the ugliness of invoking /etc/cron.d* from systemd. ;-) cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Q: systemd-timer vs cron
Hi, Is there any suggestion or guideline for pacakges that contain both systemd-timer unit setting and cronjob? Don't they conflict or not -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
