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
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 th
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 De
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.f
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 pac
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
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_
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)
Unfortuna
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-syste
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 na
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 a
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
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 possib
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 features
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, th
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 th
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
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 very
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
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
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 wi
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, the
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 j
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 a
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 w
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
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
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
34 matches
Mail list logo
