Is there any suggestion or guideline for pacakges that contain
both systemd-timer unit setting and cronjob? Don't they conflict
or not
Is there any suggestion or guideline for pacakges that contain
both systemd-timer unit setting and cronjob? Don't they conflict
or not
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.
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.
- 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.
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
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.
Unless cron finds a new maintainer (#984736), I don't think either of
these are going to happen.
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.
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.
See https://lists.debian.org/debian-devel/2020/01/msg00205.html
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.
AFAICT OnSuccess/OnFailure services don't recieve the output of the succeeding/failing service. So the mail sending service needs to digYes, this is true. These are the unit and script that I use, and I think
around in the systemd journal. Or make the service output go to a file,
FIFO or socket and then send that to a mail.
On Mar 14, Paul Wise <pabs@debian.org> 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.
I think that there is still space for cron jobs and for having a cron
package installed by default
On Mar 14, Paul Wise <pabs@debian.org> wrote:
AFAICT OnSuccess/OnFailure services don't recieve the output of the succeeding/failing service. So the mail sending service needs to digYes, 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
around in the systemd journal. Or make the service output go to a file, FIFO or socket and then send that to a mail.
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.
On Sun, 13 Mar 2022 18:02:55 +0100, Christian Kastner <ckk@debian.org>
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.I didn't take it as such, actually I simply assumed you were unaware of
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.
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:
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'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.
- 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)
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)
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
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
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=
Michael Biebl <biebl@debian.org> 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.
On Tue, 2022-03-15 at 13:28 +0000, 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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 360 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 128:35:28 |
| Calls: | 7,686 |
| Files: | 12,828 |
| Messages: | 5,711,088 |