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
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
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
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:
>
>
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
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
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
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)
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
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
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
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)
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
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
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
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
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
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,
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.
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
33 matches
Mail list logo