Re: migration from cron.daily to systemd timers

[Daniel Leidert]

Am Samstag, den 11.01.2020, 15:44 -0500 schrieb Sam Hartman:
> > > > > > "Daniel" == Daniel Leidert  writes:
> 
> Daniel> Why not simply introduce a non-Cron-related variable in
> Daniel> /etc/default/spamassassin like ENABLE_UPDATES and add it to the 
> new
> Daniel> configuration file. You can even remove the CRON variable from 
> the shipped
> Daniel> configuration file. This variable should take precendence over 
> CRON if both are
> Daniel> enabled. This would have the advantage of not polluting the 
> meaning of CRON. It
> Daniel> lets the user decide at install time, how to proceed (and if to 
> keep the
> Daniel> previous behavior), it would ship a new default like you seem to 
> wish, and it
> Daniel> would realize the suggestion by Philip. There is IMHO no need to 
> create another
> Daniel> file.
> 
> Your proposal has the negative effect of giving users who have simply
> enabled the cron script an ugly conffile update message.

It was the intention of Philip's suggestion to handle it via conffile
change/prompt (as an alternative to my debconf suggestion). Why do you consider
a conffile prompt "ugly" or "negative"? What is your suggestion?

Regards, Daniel 



signature.asc
Description: This is a digitally signed message part

Re: migration from cron.daily to systemd timers

[Sam Hartman]

> "Daniel" == Daniel Leidert  writes:


Daniel> Why not simply introduce a non-Cron-related variable in
Daniel> /etc/default/spamassassin like ENABLE_UPDATES and add it to the new
Daniel> configuration file. You can even remove the CRON variable from the 
shipped
Daniel> configuration file. This variable should take precendence over CRON 
if both are
Daniel> enabled. This would have the advantage of not polluting the meaning 
of CRON. It
Daniel> lets the user decide at install time, how to proceed (and if to 
keep the
Daniel> previous behavior), it would ship a new default like you seem to 
wish, and it
Daniel> would realize the suggestion by Philip. There is IMHO no need to 
create another
Daniel> file.

Your proposal has the negative effect of giving users who have simply
enabled the cron script an ugly conffile update message.

Re: migration from cron.daily to systemd timers

[Daniel Leidert]

Am Mittwoch, den 08.01.2020, 17:23 -0500 schrieb Noah Meyerhans:
> On Wed, Jan 08, 2020 at 10:32:07PM +0100, Philip Hands wrote:
> > I don't really care what that comment says, as that's up to the
> > maintainer of the package, and how they intend to deal with this in the
> > future, but I'm really not a fan adding unnecessary questions to debconf.
> 
> Here's my proposal for how to perform this conversion:
> 
> https://salsa.debian.org/noahm/spamassassin/commit/2b2020cbd2e43361d93d8efc1304f5575c0a83e1
> 
> If CRON=0, as is the default, then the cron.daily script is a no-op, as
> today, under systemd or non-systemd.
> 
> If CRON=1 and non systemd, then the cron.daily script performs the
> maintenance as today.
> 
> If systemd and CRON=1 and the systemd time is enabled, then the
> cron.daily script is a no-op.
> 
> If systemd and CRON=1 and the timer is disabled, then then:
> 
>a. If the administrator has created a file named
>   /etc/spamassassin/skip-timer-conversion, then the cron script will
>   perform the daily maintenance tasks.
>b. If there is no /etc/spamassassin/skip-timer-conversion file, then
>   the cron script will enable the timer, run a single invocation of
>   the maintenance task, and exit.  Future invocations of the
>   cron.daily script are no-op, as described above, due to the timer
>   being enabled.
> 
> I find the /etc/spamassassin/skip-timer-conversion file a little clunky,
> but I doubt that most people are going to bother with it, and it
> provides the flexibility to choose not to switch to the timer.

Why not simply introduce a non-Cron-related variable in
/etc/default/spamassassin like ENABLE_UPDATES and add it to the new
configuration file. You can even remove the CRON variable from the shipped
configuration file. This variable should take precendence over CRON if both are
enabled. This would have the advantage of not polluting the meaning of CRON. It
lets the user decide at install time, how to proceed (and if to keep the
previous behavior), it would ship a new default like you seem to wish, and it
would realize the suggestion by Philip. There is IMHO no need to create another
file.

Daniel


signature.asc
Description: This is a digitally signed message part

Re: migration from cron.daily to systemd timers

[Anthony DeRobertis]

On January 8, 2020 10:23:38 PM UTC, Noah Meyerhans  wrote:

>   a. If the administrator has created a file named
> /etc/spamassassin/skip-timer-conversion,

Seems to me that it'd make more sense for there to be once, system-wide file, 
instead of each package having its own. The the sysadmin can specify their 
preference once on whether to prefer cron or timers. 

I personally prefer timers, but if I didn't, then it'd be mighty annoying 
figuring out the dozens of individual use-cron flag files.

Re: migration from cron.daily to systemd timers

[Anthony DeRobertis]

On January 8, 2020 7:57:51 PM UTC, Noah Meyerhans  wrote:
>
>The big drawback of systemd timers, IMO, is that a nonzero exit code
>doesn't generate email by default the way cron does.  At smaller sites,
>anyway, this is a perfectly sensible way of being notified of problems
>with the job.

That's correct, they log the failure to the journal and/or syslog, but do not 
email. You can use OnFailure to send an email... not sure if there is a way to 
do that by default.

Also, don't think anyone has mentioned it, but "systemctl list-timers" is a 
nice advantage of timers, too. And it can actually take into account the 
randomized start delay, something no cron-equivalent could do.

Re: migration from cron.daily to systemd timers

[Michael Biebl]

Am 09.01.20 um 13:08 schrieb Michael Stone:
> On Wed, Jan 08, 2020 at 07:12:17PM -0800, Russ Allbery wrote:
>> Michael Stone  writes:
>>> On Thu, Jan 09, 2020 at 02:09:12AM +, Paul Wise wrote:
>>
 This is the main reason I haven't switched to systemd timers for my
 personal crontab, I have some jobs that generate output (diffs of
 various things mostly) but don't fail. There doesn't appear to be any
 tool to monitor a tool and send a mail if it generates output or fails,
 in the way that cron does.
>>
>>> mail -E ?
>>
>> Specifically:
>>
>>    ExecStart=/bin/sh -c '/path/to/job | /usr/bin/mail -E'
>>
>> in the service unit triggered by the timer unit should work, I think.
>> (I've not tested it.)
> 
> May need something like
> (job || echo Job failed) 2>&1 | mail -E
> or even
> 
> (job 2>&1 || echo Job failed) | tee /dev/stderr | mail -E
> 
> depending on the specific requirements, but in general this should be
> pretty straightforward


You might want to use  OnFailure=

https://www.freedesktop.org/software/systemd/man/systemd.unit.html#OnFailure=

https://serverfault.com/questions/694818/get-notification-when-systemd-monitored-service-enters-failed-state

You can set the OnFailure= action via a drop-in for individual services
without having to touch the original .service file.


With v244 it's also possible to set this OnFailure= action globally for
all services. The relevant part from the NEWS file:

> * Unit files now support top level dropin directories of the form
>   .d/ (e.g. service.d/) that may be used to add 
> configuration
>   that affects all corresponding unit files.


Or you use something like
https://github.com/joonty/systemd_mon



HTH,
Michael



signature.asc
Description: OpenPGP digital signature

Re: migration from cron.daily to systemd timers

[Michael Stone]

On Wed, Jan 08, 2020 at 07:12:17PM -0800, Russ Allbery wrote:

Michael Stone  writes:

On Thu, Jan 09, 2020 at 02:09:12AM +, Paul Wise wrote:



This is the main reason I haven't switched to systemd timers for my
personal crontab, I have some jobs that generate output (diffs of
various things mostly) but don't fail. There doesn't appear to be any
tool to monitor a tool and send a mail if it generates output or fails,
in the way that cron does.



mail -E ?


Specifically:

   ExecStart=/bin/sh -c '/path/to/job | /usr/bin/mail -E'

in the service unit triggered by the timer unit should work, I think.
(I've not tested it.)


May need something like 

(job || echo Job failed) 2>&1 | mail -E 


or even

(job 2>&1 || echo Job failed) | tee /dev/stderr | mail -E

depending on the specific requirements, but in general this should be 
pretty straightforward

Re: migration from cron.daily to systemd timers

[Russ Allbery]

Michael Stone  writes:
> On Thu, Jan 09, 2020 at 02:09:12AM +, Paul Wise wrote:

>> This is the main reason I haven't switched to systemd timers for my
>> personal crontab, I have some jobs that generate output (diffs of
>> various things mostly) but don't fail. There doesn't appear to be any
>> tool to monitor a tool and send a mail if it generates output or fails,
>> in the way that cron does.

> mail -E ?

Specifically:

ExecStart=/bin/sh -c '/path/to/job | /usr/bin/mail -E'

in the service unit triggered by the timer unit should work, I think.
(I've not tested it.)

-- 
Russ Allbery (r...@debian.org)  

Re: migration from cron.daily to systemd timers

[Michael Stone]

On Thu, Jan 09, 2020 at 02:09:12AM +, Paul Wise wrote:

This is the main reason I haven't switched to systemd timers for my
personal crontab, I have some jobs that generate output (diffs of
various things mostly) but don't fail. There doesn't appear to be any
tool to monitor a tool and send a mail if it generates output or
fails, in the way that cron does.


mail -E ?

Re: migration from cron.daily to systemd timers

[Paul Wise]

On Wed, Jan 8, 2020 at 11:45 PM Richard Laager wrote:

> We do lose the automatic cron emails

This is the main reason I haven't switched to systemd timers for my
personal crontab, I have some jobs that generate output (diffs of
various things mostly) but don't fail. There doesn't appear to be any
tool to monitor a tool and send a mail if it generates output or
fails, in the way that cron does. As the blogs you link to explain,
even if such a tool existed, systemd's options for output handling
don't really allow for such a tool to be passed the output easily.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: migration from cron.daily to systemd timers

[Richard Laager]

On 1/8/20 1:02 PM, Michael Stone wrote:
> As a third party with no particular ax to grind on this, I do wonder
> what the advantage is to adding another mechanism for this particular
> use case, given the need to somehow handle upgrades involving an
> existing (presumably working?) solution.

At my work, we recently converted all our cron jobs to system units
(service and timer pairs). We see the following advantages:

You can use systemd's dependencies. This allows you to do things like
automatically stop a related scheduled task if its service is manually
stopped (e.g. for maintenance). This can keep the scheduled task from
interfering with your work (e.g. a watchdog script restarting the "dead"
service) and/or throwing errors (because the service isn't running). In
the latter case, that might mean that you avoid needing to suppress
errors because of this normal occurrence, which means you aren't
suppressing real errors.

The service unit can be started manually. This makes it a lot easier to
debug/develop with systemd than cron (where you have to manually change
it to run at the next minute and wait). Obviously, you can still run the
scripts directly, but sometimes the problem you're working on only
manifests when it is run under cron/systemd (e.g. because of different
environment variables being missing or different [1]).

The timer units can be randomized over arbitrarily sized windows,
customized per service. This avoids load peaks, e.g. at cron.daily time.

Your scripts can write non-error debug/status information to stdout
without it resulting in an email. This info shows up in the logs, which
can be convenient. [4] Obviously, one can use logger(1) or syslog,
depending on programming language, but for trivial in-house scripts,
it's hard to beat the simplicity of just printing to stdout.

Yesterday, we implemented a new script that uses a web API where you
request an action and then poll until it completes. We wanted a timeout.
With systemd, since the service is Type=oneshot, we can just set
TimeoutStartSec= and we're done. This will kill the script if it hangs
for any reason at any step. We obviously could have implemented a
timeout in the script for that particular step, or in general, but this
was simpler.

For new/junior sysadmins, there is more overlap. Everything they learn
about systemd services applies to both scheduled tasks and those that
start at boot. That's not to say that cron is harder to learn, just that
it's another thing.

Recent versions of systemd have an analyze option to show you the next
iteration(s) of a calendar specification. This makes it easy to verify
that your calendar syntax is firing at the right times, and you haven't
mixed up hours/minutes/seconds, etc. It will also show you the
normalized form (which we prefer to use to avoid confusing humans). Some
examples from my history:
systemd-analyze calendar --iterations=5 'Mon..Fri 01:50'
systemd-analyze calendar --iterations=5 '*:0/5'
systemd-analyze calendar --iterations=5 '*:27,57'

We do lose the automatic cron emails, which some would see as a
downside, though there are ways to get them on a service-by-service
basis. [2] [3] In our particular case, anything that is _expected_ to
send an email was already doing so manually (i.e. calling mail(1)) for
other integration reasons. In our particular case, though, using systemd
units was preferable from an alerting perspective, as we already have an
Icinga check that runs `systemctl list-units --failed` and alerts if any
service (scheduled or daemon style) has failed for any reason.

The systemd units are "fluffier" (more lines and more characters of
overhead) than crontabs, but that's not a true increase in complexity.
All told, with this change, it feels like things are a bit simpler and
easier to work on while achieving a bit better results. It's a modest
"quality of life" improvement.

This is _not_ my blog, but I read it regularly and comment periodically:
[1] https://utcc.utoronto.ca/~cks/space/blog/linux/SortCronLocaleDanger
[2] https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdTimersAndErrors
[3] https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdTimersMailNotes

This one quotes my comment on article [2]:
[4]
https://utcc.utoronto.ca/~cks/space/blog/sysadmin/NotificationsVersusLogs

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Re: migration from cron.daily to systemd timers

[Richard Laager]

On 1/8/20 4:25 PM, Josh Triplett wrote:
> (I would suggest doing the same for the cron job, for new installations:
> put the script itself in /usr/lib/spamassassin or similar, and document
> that people can enable it by either enabling the systemd timer, linking
> the script from cron.daily, or copying the script to cron.daily if they
> really want to modify it.)

It seems like this would work well. That's better than my previous
proposal and the current commit, as it doesn't result in a cron.daily
script starting just to exit.

It looks like the existing commit uses /usr/sbin/spamassassin-maint, so
I'll use that instead for the example. I personally wouldn't put this
script in the PATH, but that's a separate issue.

The migration would then look something like this:

[ -e /etc/default/spamassassin ] && . /etc/default/spamassassin
if ! [ -L /etc/cron.daily/spamassassin ] &&
   ! TODO_check_for_local_changes ; then
if [ "$CRON" = "1" ] ; then
if [ -d /run/systemd/system ]; then
systemctl enable spamassassin-daily-maintenance.timer
rm -f /etc/cron.daily/spamassassin
else
ln -sf /usr/sbin/spamassassin-maint \
/etc/cron.daily/spamassassin
fi
else
rm -f /etc/cron.daily/spamassassin
fi
fi

So, if the user changed it, just leave everything alone. If they didn't
change it and aren't using it, remove it. If they didn't change it but
are using it, replace it with a symlink or a systemd unit, depending on
whether systemd is in use.

This covers everything except the case of: they're using it, but did not
modify it, and are using systemd, but don't want systemd timers. In that
case, the user would have to disable the systemd timer and add the
symlink. I'd mention this in the NEWS.

With this proposeal, the maintenance script should also stop checking
CRON= (or for the systemd timer), and CRON= should be removed from
/etc/default/spamassassin (though that needs to be done AFTER the check
above fires).

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Re: migration from cron.daily to systemd timers

[Josh Triplett]

Noah Meyerhans wrote:
> Spamassassin has traditionally supplied a cron.daily script.  I'd like
> to provide the same functionality via a systemd timer, while still
> providing cron as a fallback.  For the most part, this is
> straightforward, but there are a few details on which I'd like feedback.
> 
> Current the cron.daily script is a no-op by default, and functionality
> is enabled by setting CRON=1 in /etc/default/spamassassin.  For users
> running systemd, I'd expect to ship a timer unit that is disabled by
> default, and have them enable it with:
> 
> $ systemctl enable spamassassin-daily-maintenance.timer
> 
> Any issues with that?

That sounds like the correct approach. We should not have scripts that
run just to check a configuration variable and see if they should
immediately exit; disabled services should be *disabled* and not run at
all.

(I would suggest doing the same for the cron job, for new installations:
put the script itself in /usr/lib/spamassassin or similar, and document
that people can enable it by either enabling the systemd timer, linking
the script from cron.daily, or copying the script to cron.daily if they
really want to modify it.)

> If the timer and the cron activity are both enabled, the cron script
> will be a no-op.  This is accomplished with the following in the cron
> script:
> 
> if command -v systemctl > /dev/null 2>&1 &&
>systemctl is-enabled spamassassin-daily-maintenance.timer; then
> exit 0
> fi
> 
> Would you do this a different way?

I've seen multiple discussions about updating Debian's version of cron
to a newer version/fork, which includes support for handling this
internal to cron, just as systemd avoids running an init script if a
corresponding service exists. That seems vastly preferable to individual
scripts waking up periodically and performing such a check. I would
suggest checking with the cron maintainers regarding the status of such
work.

Re: migration from cron.daily to systemd timers

[Noah Meyerhans]

On Wed, Jan 08, 2020 at 10:32:07PM +0100, Philip Hands wrote:
> I don't really care what that comment says, as that's up to the
> maintainer of the package, and how they intend to deal with this in the
> future, but I'm really not a fan adding unnecessary questions to debconf.

Here's my proposal for how to perform this conversion:

https://salsa.debian.org/noahm/spamassassin/commit/2b2020cbd2e43361d93d8efc1304f5575c0a83e1

If CRON=0, as is the default, then the cron.daily script is a no-op, as
today, under systemd or non-systemd.

If CRON=1 and non systemd, then the cron.daily script performs the
maintenance as today.

If systemd and CRON=1 and the systemd time is enabled, then the
cron.daily script is a no-op.

If systemd and CRON=1 and the timer is disabled, then then:

   a. If the administrator has created a file named
  /etc/spamassassin/skip-timer-conversion, then the cron script will
  perform the daily maintenance tasks.
   b. If there is no /etc/spamassassin/skip-timer-conversion file, then
  the cron script will enable the timer, run a single invocation of
  the maintenance task, and exit.  Future invocations of the
  cron.daily script are no-op, as described above, due to the timer
  being enabled.

I find the /etc/spamassassin/skip-timer-conversion file a little clunky,
but I doubt that most people are going to bother with it, and it
provides the flexibility to choose not to switch to the timer.

noah

Re: migration from cron.daily to systemd timers

[Noah Meyerhans]

On Wed, Jan 08, 2020 at 10:09:58PM +0100, Stephan Seitz wrote:
> > visible to administrators.  IMO the migration to systemd timers can be
> > done more smoothly, so it's still preferable.
> 
> Well, since you need to support non-systemd systems as well (like mine) the
> cron script is still needed (I don’t think these timers work with elogind).
> 
> So the migration can only take place on systems running systemd.

That is a given, and has been stated more than once in this thread, from
the beginning.

Re: migration from cron.daily to systemd timers

[Russ Allbery]

Stephan Seitz  writes:
> On Mi, Jan 08, 2020 at 02:57:51 -0500, Noah Meyerhans wrote:

>> visible to administrators.  IMO the migration to systemd timers can be
>> done more smoothly, so it's still preferable.

> Well, since you need to support non-systemd systems as well (like mine)
> the cron script is still needed (I don’t think these timers work with
> elogind).

> So the migration can only take place on systems running systemd.

All of the proposals that Noah has put forward or that have been discussed
in this thread only take place on systems running systemd.

-- 
Russ Allbery (r...@debian.org)  

Re: migration from cron.daily to systemd timers

[Philip Hands]

Daniel Leidert  writes:

> Am Mittwoch, den 08.01.2020, 08:17 +0100 schrieb Philip Hands:
>
> [..]
>> How about modifying the shipped /etc/default/spamassassin to include a
>> comment explaining what's going on, and how to enable the timer instead?
>
> It seems I misread this part at first. Is it your suggestion to keep the
> default behavior and explain how to enable the timer instead?

My suggestion was simply that by modifying the file, one provokes a
question on upgrade about whether the administrator wants their modified
version (presumably modified to have CRON=1 set) or the new one from the
maintainer (now with a nice comment about what's new, that should be
enough to give the admin all the information they need).

If a system has an unmodified file (so with CRON=0, among other things)
then it gets quietly upgraded to the one with a comment, which might
even turn out to be useful, when someone used to the old ways of doing
things goes to set CRON=1 and gets the chance to learn something new.

I don't really care what that comment says, as that's up to the
maintainer of the package, and how they intend to deal with this in the
future, but I'm really not a fan adding unnecessary questions to debconf.

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: migration from cron.daily to systemd timers

[Stephan Seitz]

On Mi, Jan 08, 2020 at 02:57:51 -0500, Noah Meyerhans wrote:

visible to administrators.  IMO the migration to systemd timers can be
done more smoothly, so it's still preferable.


Well, since you need to support non-systemd systems as well (like mine) 
the cron script is still needed (I don’t think these timers work with 
elogind).


So the migration can only take place on systems running systemd.

Shade and sweet water!

Stephan

--
|If your life was a horse, you'd have to shoot it.|

Re: migration from cron.daily to systemd timers

[Philip Hands]

Daniel Leidert  writes:

> Am Mittwoch, den 08.01.2020, 15:36 +0100 schrieb Philipp Kern:
>> On 2020-01-08 14:27, Daniel Leidert wrote:
>> > And what s the benefit of this change: Getting rid of cron?
>> >
>> > The very simple thing is: CRON=1 enables a cron job. It does *not* say:
>> > "Please
>> > enable something different as long as it achieves the same." There is
>> > nothing
>> > wrong with the cron job and it works perfectly fine. So I don't want to
>> > have it
>> > replaced by something less transparent.
>> >
>> > Why do you resist the appropriate behavior of raising a question
>> > whether the
>> > user wants you to replace cron by systemd?
>>
>> I don't think yelling in this way is helpful.
>
> Stop it. Right here and right now. I didn't yell at anybody. I raised some
> serious questions I believe are justified by your comments.

Erm, no -- I think you're conflating two Phils now (he has an extra 'p',
and a different surname ;-) )

The strong reaction he's complaining about was provoked by what I said.

I'm not really sure why you'd react like that, but just in case it
helps, I'll try to clarify where I'm coming from:

I have no particular opinion about keeping or discarding cron, but I do
object to questions that almost nobody wants to answer being shoved into
debconf in a way that means they may end up being duplicated across
multiple packages, and will then be left behind by future developments,
while not being easy enough to remove for them to ever go away.

If that can instead be dealt with by adding a useful comment in a file
that might well be the place that one would be looking when one needed
the information in that comment, then that seems like a better way of
doing the same thing.

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: migration from cron.daily to systemd timers

[Didier 'OdyX' Raboud]

Le mercredi, 8 janvier 2020, 16.33:28 h CET Daniel Leidert a écrit :
> Am Mittwoch, den 08.01.2020, 15:36 +0100 schrieb Philipp Kern:
> > I think there needs to be a sensible choice for *periodic jobs* that we
> > should document as the default unless there is a reason to use something
> > else. It does not need to be cron, though.
> 
> Then go the appropriate way. Get a resolution if the Debian project is ok
> with the new default (…)

We _literally_ just passed a resolution [0] saying:
> Packages may use any systemd facility at the package maintainer's
> discretion, provided that this is consistent with other Policy requirements 
> (…)

Policy says conffile changes must not be overriden; not that their meaning or 
semantics can never change.

> If there is such a resolution: Change the default for new
> installations and leave existing installations a choice.

Philip's proposal at <87eewah0ws@hands.com> ( modify the shipped /etc/
default/spamassassin so that hosts with changes get a prompt; and others just 
start using the systemd timers) seems like a very nice strategy that seem to 
cover your needs.

Cheers,
OdyX

[0] https://www.debian.org/vote/2019/vote_002#textb

Re: migration from cron.daily to systemd timers

[Matthew Woodcraft]

Russ Allbery wrote:

The one exception I can think of is if someone really wants to
customize the [spamassassin daily] job. That can be a little more
tedious to do with timer units. Right now, I think there's a bunch of
logic in the /etc/cron.daily script that someone could in theory
change. But I'm not sure how often that happens or how useful that
would be.


I've modified that script in the past, to add third-party rule sources.

As far as I can see, in the current packaging if you wanted to do that
the simplest way would still be to modify that script.

Though I don't know if there are any useful third-party rule sources
these days.

-M-

Re: migration from cron.daily to systemd timers

[Noah Meyerhans]

On Wed, Jan 08, 2020 at 11:25:56AM -0800, Russ Allbery wrote:
> > As a third party with no particular ax to grind on this, I do wonder
> > what the advantage is to adding another mechanism for this particular
> > use case, given the need to somehow handle upgrades involving an
> > existing (presumably working?) solution.
> 
> Timer units allow the administrator to easily enable and disable them
> without mucking around with changing configuration files and then dealing
> with merging changes to configuration files.  (I just had to deal with
> this with a spamassassin upgrade as part of upgrading to the latest
> stable.)  They also handle suspended systems, time changes, and other
> related things better than cron jobs (anacron helps with some of that, of
> course).

It's also quite a bit easier for an admin to adjust the period of a
systemd timer than it is for a cron.daily script.

cron.daily scripts are also run serially.  The random delayed start
feature that the spamassassin job uses to reduce load on the sa-update
servers doesn't really play nicely with this, as it ends up delaying the
start of subsequent jobs for no good reason.  We could avoid this with
cron.d, and as has been pointed out elsewhere in this thread, that might
be desirable anyway, but that's still a migration that is going to be
visible to administrators.  IMO the migration to systemd timers can be
done more smoothly, so it's still preferable.

The big drawback of systemd timers, IMO, is that a nonzero exit code
doesn't generate email by default the way cron does.  At smaller sites,
anyway, this is a perfectly sensible way of being notified of problems
with the job.

noah

Re: migration from cron.daily to systemd timers

[Russ Allbery]

Michael Stone  writes:
> On Wed, Jan 08, 2020 at 10:36:02AM -0800, Russ Allbery wrote:

>> Could you be specific about what you prefer about a cron job over a
>> systemd timer unit?  If it's just that you are familiar with cron jobs
>> and not systemd timer units, I'm sympathetic but I don't think that's a
>> very strong argument for the additional complexity you're asking for.
>> Other software in Debian is already using systemd timer units, so
>> you're likely to have to become familiar with them at some point
>> regardless.  But if there is some other concrete use case, I'd love to
>> talk about it in specific detail rather than just in generalities.

> As a third party with no particular ax to grind on this, I do wonder
> what the advantage is to adding another mechanism for this particular
> use case, given the need to somehow handle upgrades involving an
> existing (presumably working?) solution.

Timer units allow the administrator to easily enable and disable them
without mucking around with changing configuration files and then dealing
with merging changes to configuration files.  (I just had to deal with
this with a spamassassin upgrade as part of upgrading to the latest
stable.)  They also handle suspended systems, time changes, and other
related things better than cron jobs (anacron helps with some of that, of
course).

-- 
Russ Allbery (r...@debian.org)  

Re: migration from cron.daily to systemd timers

[Michael Stone]

On Wed, Jan 08, 2020 at 10:36:02AM -0800, Russ Allbery wrote:

Could you be specific about what you prefer about a cron job over a
systemd timer unit?  If it's just that you are familiar with cron jobs and
not systemd timer units, I'm sympathetic but I don't think that's a very
strong argument for the additional complexity you're asking for.  Other
software in Debian is already using systemd timer units, so you're likely
to have to become familiar with them at some point regardless.  But if
there is some other concrete use case, I'd love to talk about it in
specific detail rather than just in generalities.


As a third party with no particular ax to grind on this, I do wonder 
what the advantage is to adding another mechanism for this particular 
use case, given the need to somehow handle upgrades involving an 
existing (presumably working?) solution. 

Re: migration from cron.daily to systemd timers

[Daniel Leidert]

Am Mittwoch, den 08.01.2020, 12:56 -0500 schrieb Noah Meyerhans:
> On Wed, Jan 08, 2020 at 02:18:34PM +0100, Daniel Leidert wrote:
> > > Yeah, that's my reaction as well.  The point is to run the job
> > > periodically.
> > 
> > No. The configuration says CRON=1. It doesn't say PERIODIC_CHECKS=1. Your
> > behavior here is pretty similar to Microsofts: Let the user decide if
> > updates
> > shouldn't be automatically installed and still install a bunch of them 
> > automatically without his approval independent of his decision.
> > 
> > I have enabled a cron-job, not a systemd timer unit. And I don't want you
> > to
> > silently override this.
> 
> You haven't enabled a cron job, though.

I have. The configuration clearly states:

# Cronjob
# Set to anything but 0 to enable the cron job to automatically update
# spamassassin's rules on a nightly basis
CRON=1

[..]
> Had the variable been named PERIODIC_CHECKS or something like that,
> would your objections still stand?

If I would have just enabled periodic updates it would IMHO indeed give you
more freedom (as my own comment at the top already implies). I'd still ask you
to make a transition and make it transparent.

It would also be one possibility to transition from CRON=1 to
PERIODIC_UPDATES=1. If the latter is set, systemd should be used. Debconf can
be used to determine if this transition should be done automatically. Or
document it in README/NEWS. 

Regards, Daniel


signature.asc
Description: This is a digitally signed message part

Re: migration from cron.daily to systemd timers

[Russ Allbery]

Daniel Leidert  writes:
> Am Dienstag, den 07.01.2020, 20:19 -0800 schrieb Russ Allbery:

>> Yeah, that's my reaction as well.  The point is to run the job
>> periodically.

> No. The configuration says CRON=1. It doesn't say
> PERIODIC_CHECKS=1. Your behavior here is pretty similar to Microsofts:
> Let the user decide if updates shouldn't be automatically installed and
> still install a bunch of them automatically without his approval
> independent of his decision.

> I have enabled a cron-job, not a systemd timer unit. And I don't want
> you to silently override this.

I'm confused by why this matters so much to you, and maybe that would help
in making some forward progress rather than us all just repeating our own
opinions.

Could you be specific about what you prefer about a cron job over a
systemd timer unit?  If it's just that you are familiar with cron jobs and
not systemd timer units, I'm sympathetic but I don't think that's a very
strong argument for the additional complexity you're asking for.  Other
software in Debian is already using systemd timer units, so you're likely
to have to become familiar with them at some point regardless.  But if
there is some other concrete use case, I'd love to talk about it in
specific detail rather than just in generalities.

>> I share your dubiousness that adding tons of debconf prompts for cases
>> like this (there are likely to be a bunch of them) makes sense.

> If you share that "dubiousness" I really have to wonder why Noah himself
> raised the question in the first place.

Because this is how you do good technical design: Raise all the possible
feasible design alternatives so that they can be examined and considered.
Thank you for raising that one!  It's absolutely worth thinking about.

-- 
Russ Allbery (r...@debian.org)  

Re: migration from cron.daily to systemd timers

[Noah Meyerhans]

On Wed, Jan 08, 2020 at 02:18:34PM +0100, Daniel Leidert wrote:
> > Yeah, that's my reaction as well.  The point is to run the job
> > periodically.
> 
> No. The configuration says CRON=1. It doesn't say PERIODIC_CHECKS=1. Your
> behavior here is pretty similar to Microsofts: Let the user decide if updates
> shouldn't be automatically installed and still install a bunch of them 
> automatically without his approval independent of his decision.
> 
> I have enabled a cron-job, not a systemd timer unit. And I don't want you to
> silently override this.

You haven't enabled a cron job, though.  You've edited a file in
/etc/default.  The variable happens to be named CRON, but that was never
a good choice.  That name was introduced >15 years ago by a previous
package maintainer, and is only there today due to inertia and a lack of
real need to move to something else.

Had the variable been named PERIODIC_CHECKS or something like that,
would your objections still stand?

noah

Re: migration from cron.daily to systemd timers

[Michael Stone]

On Wed, Jan 08, 2020 at 05:15:36PM +0100, Daniel Leidert wrote:

It seems I misread this part at first.


So maybe you should slow down on the emails?

Re: migration from cron.daily to systemd timers

[Daniel Leidert]

Am Mittwoch, den 08.01.2020, 08:17 +0100 schrieb Philip Hands:

[..]
> How about modifying the shipped /etc/default/spamassassin to include a
> comment explaining what's going on, and how to enable the timer instead?

It seems I misread this part at first. Is it your suggestion to keep the
default behavior and explain how to enable the timer instead?

Regards, Daniel


signature.asc
Description: This is a digitally signed message part

Re: migration from cron.daily to systemd timers

[Daniel Leidert]

Am Mittwoch, den 08.01.2020, 15:36 +0100 schrieb Philipp Kern:
> On 2020-01-08 14:27, Daniel Leidert wrote:
> > And what s the benefit of this change: Getting rid of cron?
> > 
> > The very simple thing is: CRON=1 enables a cron job. It does *not* say: 
> > "Please
> > enable something different as long as it achieves the same." There is 
> > nothing
> > wrong with the cron job and it works perfectly fine. So I don't want to 
> > have it
> > replaced by something less transparent.
> > 
> > Why do you resist the appropriate behavior of raising a question 
> > whether the
> > user wants you to replace cron by systemd?
> 
> I don't think yelling in this way is helpful.

Stop it. Right here and right now. I didn't yell at anybody. I raised some
serious questions I believe are justified by your comments.

> "Run by cron" used to be 
> the way of saying that it's a periodic job - as the only means of 
> accomplishing this and it turns out it was a misnomer already given that 
> it's run from cron.daily, which might be anacron on some systems and 
> cron on others.

That doesn't mean that having another alternative is a justification to assume
the user is ok having the default solution replaced (silently). We usually ask
first. And even if we change something, we document it (NEWS.Debian) and also
document how to restore the default behavior (README.Debian).

But you seem to resist this. And I'm not ok with that ... especially because it
affects my systems.

> I think there needs to be a sensible choice for *periodic jobs* that we 
> should document as the default unless there is a reason to use something 
> else. It does not need to be cron, though.

Then go the appropriate way. Get a resolution if the Debian project is ok with
the new default (here it clearly seems your goal is to replace cron by
systemd!). If there is such a resolution: Change the default for new
installations and leave existing installations a choice.

But don't ceate facts and leave scorched earth behind.

Regards, Daniel


signature.asc
Description: This is a digitally signed message part

Re: migration from cron.daily to systemd timers

[Raphael Hertzog]

On Wed, 08 Jan 2020, Daniel Leidert wrote:
> > This strikes me as clutter that will never be removed from debconf, so
> > let's not decide to do that for every package that might need a timer.
> 
> Why should this question ever been removed? What is your goal? Getting rid of
> cron-jobs?

The question is not yet added. We should ask ourselves if it's actually
useful before adding it. Is the feature important enough to ask 50+
translators translate a question on whether the user prefers to use cron
or systemd to run some periodic checks?

My answer is no. Yours is apparently yes.

> > How about modifying the shipped /etc/default/spamassassin to include a
> > comment explaining what's going on, and how to enable the timer instead?
> > 
> > Anyone who's set CRON=1 will then get warned about the maintainer's
> > modified version, which should catch their attention.  Everyone else
> > will get a handy hint about the new setup if they ever go to set CRON=1
> > in future.
> 
> And what s the benefit of this change: Getting rid of cron?

He explained the benefits. Informing users who care enough to look
into the relevant configuration files and/or those who modified the said
files, without annoying everybody else with a question that they don't
care about.

> The very simple thing is: CRON=1 enables a cron job. It does *not* say: 
> "Please
> enable something different as long as it achieves the same." There is nothing
> wrong with the cron job and it works perfectly fine. So I don't want to have 
> it
> replaced by something less transparent.

This is the third time that you are saying this in this thread. Please let
others disagree with you without repeating yourself.

FWIW, I agree with other that CRON=1 really means that the use desires to
have the periodic check running. I also agree that a debconf prompt is
overkill for this choice.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: migration from cron.daily to systemd timers

[Philipp Kern]

On 2020-01-08 14:27, Daniel Leidert wrote:

And what s the benefit of this change: Getting rid of cron?

The very simple thing is: CRON=1 enables a cron job. It does *not* say: 
"Please
enable something different as long as it achieves the same." There is 
nothing
wrong with the cron job and it works perfectly fine. So I don't want to 
have it

replaced by something less transparent.

Why do you resist the appropriate behavior of raising a question 
whether the

user wants you to replace cron by systemd?


I don't think yelling in this way is helpful. "Run by cron" used to be 
the way of saying that it's a periodic job - as the only means of 
accomplishing this and it turns out it was a misnomer already given that 
it's run from cron.daily, which might be anacron on some systems and 
cron on others.


I think there needs to be a sensible choice for *periodic jobs* that we 
should document as the default unless there is a reason to use something 
else. It does not need to be cron, though.


Kind regards
Philipp Kern

Re: migration from cron.daily to systemd timers

[Daniel Leidert]

Am Mittwoch, den 08.01.2020, 08:17 +0100 schrieb Philip Hands:
> Daniel Leidert  writes:
> ...
> > Please ask during installation and give the question an appropriate
> > priority.
> > By choosing the priority you can even achieve a "silent" transition for
> > "normal" users and let more advanced users decide.
> 
> This strikes me as clutter that will never be removed from debconf, so
> let's not decide to do that for every package that might need a timer.

Why should this question ever been removed? What is your goal? Getting rid of
cron-jobs?

> How about modifying the shipped /etc/default/spamassassin to include a
> comment explaining what's going on, and how to enable the timer instead?
> 
> Anyone who's set CRON=1 will then get warned about the maintainer's
> modified version, which should catch their attention.  Everyone else
> will get a handy hint about the new setup if they ever go to set CRON=1
> in future.

And what s the benefit of this change: Getting rid of cron?

The very simple thing is: CRON=1 enables a cron job. It does *not* say: "Please
enable something different as long as it achieves the same." There is nothing
wrong with the cron job and it works perfectly fine. So I don't want to have it
replaced by something less transparent.

Why do you resist the appropriate behavior of raising a question whether the
user wants you to replace cron by systemd?

Regards, Daniel




signature.asc
Description: This is a digitally signed message part

Re: migration from cron.daily to systemd timers

[Daniel Leidert]

Am Dienstag, den 07.01.2020, 20:19 -0800 schrieb Russ Allbery:
> Noah Meyerhans  writes:
> > On Wed, Jan 08, 2020 at 02:43:08AM +0100, Daniel Leidert wrote:
> > > I disagree here. I don't want you to overrule my decision for a
> > > cron-script. If a user has enabled a cron-job you shouldn't change that
> > > to a systemd timer unit without the user's explicit approval.
> > I'm not sure that I take CRON=1 as meaning "I want to use cron forever".
> > I'd rather interpret it as "I want to enable spamassassin's daily
> > maintenance job".  The details of how it's accomplished aren't really
> > relevant, IMO.
> 
> Yeah, that's my reaction as well.  The point is to run the job
> periodically.

No. The configuration says CRON=1. It doesn't say PERIODIC_CHECKS=1. Your
behavior here is pretty similar to Microsofts: Let the user decide if updates
shouldn't be automatically installed and still install a bunch of them 
automatically without his approval independent of his decision.

I have enabled a cron-job, not a systemd timer unit. And I don't want you to
silently override this.

> A timer unit is easier to enable and disable.

That's just your opinion and not a fact. And FWIW I disagree.

> I think most
> users (I'm one) will not care about how this is done.

I do - as a Debian user and as a spamassassin user.

[use a debconf question]
> > Yeah, that's probably the best way in terms of user flexibility.  I'm
> > not convinced it's necessary, though, and I don't like the idea of all
> > the other packages undergoing similar transitions all having to
> > introduce similar debconf questions.
> 
> I share your dubiousness that adding tons of debconf prompts for cases
> like this (there are likely to be a bunch of them) makes sense.

If you share that "dubiousness" I really have to wonder why Noah himself raised
the question in the first place.

Regards, Daniel


signature.asc
Description: This is a digitally signed message part

Re: migration from cron.daily to systemd timers

[Philip Hands]

Daniel Leidert  writes:
...
> Please ask during installation and give the question an appropriate priority.
> By choosing the priority you can even achieve a "silent" transition for
> "normal" users and let more advanced users decide.

This strikes me as clutter that will never be removed from debconf, so
let's not decide to do that for every package that might need a timer.

How about modifying the shipped /etc/default/spamassassin to include a
comment explaining what's going on, and how to enable the timer instead?

Anyone who's set CRON=1 will then get warned about the maintainer's
modified version, which should catch their attention.  Everyone else
will get a handy hint about the new setup if they ever go to set CRON=1
in future.

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: migration from cron.daily to systemd timers

[Russ Allbery]

Noah Meyerhans  writes:
> On Wed, Jan 08, 2020 at 02:43:08AM +0100, Daniel Leidert wrote:

>> I disagree here. I don't want you to overrule my decision for a
>> cron-script. If a user has enabled a cron-job you shouldn't change that
>> to a systemd timer unit without the user's explicit approval.

> I'm not sure that I take CRON=1 as meaning "I want to use cron forever".
> I'd rather interpret it as "I want to enable spamassassin's daily
> maintenance job".  The details of how it's accomplished aren't really
> relevant, IMO.

Yeah, that's my reaction as well.  The point is to run the job
periodically.  A timer unit is easier to enable and disable.  I think most
users (I'm one) will not care about how this is done.

The one exception I can think of is if someone really wants to customize
the job.  That can be a little more tedious to do with timer units.  Right
now, I think there's a bunch of logic in the /etc/cron.daily script that
someone could in theory change.  But I'm not sure how often that happens
or how useful that would be.

> Yeah, that's probably the best way in terms of user flexibility.  I'm
> not convinced it's necessary, though, and I don't like the idea of all
> the other packages undergoing similar transitions all having to
> introduce similar debconf questions.

I share your dubiousness that adding tons of debconf prompts for cases
like this (there are likely to be a bunch of them) makes sense.

Thank you for raising this!  I'm watching the thread closely since I think
the conclusions here should probably end up in Policy at least in part.

-- 
Russ Allbery (r...@debian.org)  

Re: migration from cron.daily to systemd timers

[Noah Meyerhans]

On Wed, Jan 08, 2020 at 02:43:08AM +0100, Daniel Leidert wrote:
> > For upgrades from versions that did not include the timer, should I
> > enable the systemd timer if the user has set CRON=1?
> 
> I disagree here. I don't want you to overrule my decision for a cron-script. 
> If
> a user has enabled a cron-job you shouldn't change that to a systemd timer 
> unit
> without the user's explicit approval.

I'm not sure that I take CRON=1 as meaning "I want to use cron forever".
I'd rather interpret it as "I want to enable spamassassin's daily
maintenance job".  The details of how it's accomplished aren't really
relevant, IMO.

> Please ask during installation and give the question an appropriate priority.
> By choosing the priority you can even achieve a "silent" transition for
> "normal" users and let more advanced users decide.

Yeah, that's probably the best way in terms of user flexibility.  I'm
not convinced it's necessary, though, and I don't like the idea of all
the other packages undergoing similar transitions all having to
introduce similar debconf questions.

noah

Re: migration from cron.daily to systemd timers

[Daniel Leidert]

Am Dienstag, den 07.01.2020, 16:18 -0500 schrieb Noah Meyerhans:

[..]
> For upgrades from versions that did not include the timer, should I
> enable the systemd timer if the user has set CRON=1?

I disagree here. I don't want you to overrule my decision for a cron-script. If
a user has enabled a cron-job you shouldn't change that to a systemd timer unit
without the user's explicit approval.

> Or should I leave
> the timer disabled and preserve the original behavior via cron.daily?

See below for a possible "middle way".

[..]
> If the timer and the cron activity are both enabled, the cron script
> will be a no-op.  This is accomplished with the following in the cron
> script:
> 
> if command -v systemctl > /dev/null 2>&1 &&
>systemctl is-enabled spamassassin-daily-maintenance.timer; then
> exit 0
> fi

Sounds fine.

> Would you do this a different way?

Please ask during installation and give the question an appropriate priority.
By choosing the priority you can even achieve a "silent" transition for
"normal" users and let more advanced users decide.

Regards, Daniel


signature.asc
Description: This is a digitally signed message part

Re: migration from cron.daily to systemd timers

[Noah Meyerhans]

On Tue, Jan 07, 2020 at 05:32:47PM -0600, Richard Laager wrote:
> Could you check for local modifications and only enable the timer if
> there were NOT local modifications?
> 
> [ -e /etc/default/spamassassin ] && . /etc/default/spamassassin
> if [ -d /run/systemd/system ] && [ "$CRON" = "1" ] &&
>! some_check_for_local_modifications
> then
> systemctl enable spamassassin-daily-maintenance.timer
> fi

Since existing cron.daily scripts won't have any knowledge of the timer,
one possible transition process could involve having the installed cron
script unconditionally enable the timer when it runs.  Users who are
running with a modified script in place will continue to do so.  Users
who are running unmodified scripts, or who revert their system to the
original script during the package upgrade, will get the new behavior
which will perform the transition.

> If it was me, I'd just check for whether systemd is running (e.g. [ -d
> /run/systemd/system ]), not whether the timer unit is enabled. That way,
> at least moving forward, you're only supporting two scenarios (systemd
> uses the units, non-systemd uses cron) rather than three (those two plus
> the option of systemd systems still using cron).

My expectation is that there will be some systemd users who will still
prefer cron for some reason.  Those users could, obviously, just modify
the cron.daily script to remove the systemd conditional, but if we can
trivially support them, then I don't mind doing so.  On the other hand,
transitioning people to the timer wouldn't upset me at all either.

> If you were doing this new, I would suggest that you use cron.d instead
> of cron.daily. Then check for systemd by prefixing your command with:
>   [ -d /run/systemd/system ] || ...
> This way, if the user installs systemd-cron (which replaces crond and
> generates systemd service & timer units from cron files), it will not
> generate units for the cron job. See:
> https://github.com/systemd-cron/systemd-cron/blob/master/src/bin/systemd-crontab-generator.py#L335

I hadn't considered systemd-cron.  Thanks for pointing this out...

noah

Re: migration from cron.daily to systemd timers

[Richard Laager]

On 1/7/20 3:18 PM, Noah Meyerhans wrote:
> Current the cron.daily script is a no-op by default, and functionality
> is enabled by setting CRON=1 in /etc/default/spamassassin.  For users
> running systemd, I'd expect to ship a timer unit that is disabled by
> default, and have them enable it with:
> 
> $ systemctl enable spamassassin-daily-maintenance.timer

This seems correct. It is the systemd native way to do it.

> For upgrades from versions that did not include the timer, should I
> enable the systemd timer if the user has set CRON=1?  Or should I leave
> the timer disabled and preserve the original behavior via cron.daily?
> Since the cron script is a conffile, and may have local modifications, I
> think it should be left in place, but would take confirmation.  It'd be
> possible to perform the migration while still preserving local
> modifications, e.g. by having the shipped cron script enable the unit
> file, but IMO that would be gross.

Could you check for local modifications and only enable the timer if
there were NOT local modifications?

[ -e /etc/default/spamassassin ] && . /etc/default/spamassassin
if [ -d /run/systemd/system ] && [ "$CRON" = "1" ] &&
   ! some_check_for_local_modifications
then
systemctl enable spamassassin-daily-maintenance.timer
fi

> If the timer and the cron activity are both enabled, the cron script
> will be a no-op.  This is accomplished with the following in the cron
> script:
> 
> if command -v systemctl > /dev/null 2>&1 &&
>systemctl is-enabled spamassassin-daily-maintenance.timer; then
> exit 0
> fi
> 
> Would you do this a different way?
If it was me, I'd just check for whether systemd is running (e.g. [ -d
/run/systemd/system ]), not whether the timer unit is enabled. That way,
at least moving forward, you're only supporting two scenarios (systemd
uses the units, non-systemd uses cron) rather than three (those two plus
the option of systemd systems still using cron).

If you were doing this new, I would suggest that you use cron.d instead
of cron.daily. Then check for systemd by prefixing your command with:
  [ -d /run/systemd/system ] || ...
This way, if the user installs systemd-cron (which replaces crond and
generates systemd service & timer units from cron files), it will not
generate units for the cron job. See:
https://github.com/systemd-cron/systemd-cron/blob/master/src/bin/systemd-crontab-generator.py#L335

Unfortunately, there is currently no equivalent for /etc/cron.daily, as
systemd-cron just runs run-parts. It does not convert each cron.daily
script into a separate service. I filed a feature request for that back
in 2016, and it's gotten another look recently. I may have some time to
work on it again this year and propose a patch if nobody beats me to it:
https://github.com/systemd-cron/systemd-cron/issues/47

If you wanted, you could migrate from /etc/cron.daily to /etc/cron.d and
then apply this approach, but you'd still have the "local modifications"
problem.

If you are willing to drop support for direct local modifications, then
you could use cron.d and disable the script in cron.daily. This would
give you the simplest solution moving forward, but would require
explicit action from anyone who had customized the cron.daily script.

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Re: migration from cron.daily to systemd timers

[Marco d'Itri]

On Jan 07, Noah Meyerhans  wrote:

> is enabled by setting CRON=1 in /etc/default/spamassassin.  For users
> running systemd, I'd expect to ship a timer unit that is disabled by
> default, and have them enable it with:
> 
> $ systemctl enable spamassassin-daily-maintenance.timer
> 
> Any issues with that?
Looks good to me.

> For upgrades from versions that did not include the timer, should I
> enable the systemd timer if the user has set CRON=1?  Or should I leave
This would be nicer, but OTOH you correctly argue that the cron job 
could have been modified locally: dealing with all this may not be too 
much complex or fragile.
But you can also implement this later at any time, there is no need to 
try right now.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

migration from cron.daily to systemd timers

[Noah Meyerhans]

Spamassassin has traditionally supplied a cron.daily script.  I'd like
to provide the same functionality via a systemd timer, while still
providing cron as a fallback.  For the most part, this is
straightforward, but there are a few details on which I'd like feedback.

Current the cron.daily script is a no-op by default, and functionality
is enabled by setting CRON=1 in /etc/default/spamassassin.  For users
running systemd, I'd expect to ship a timer unit that is disabled by
default, and have them enable it with:

$ systemctl enable spamassassin-daily-maintenance.timer

Any issues with that?

For upgrades from versions that did not include the timer, should I
enable the systemd timer if the user has set CRON=1?  Or should I leave
the timer disabled and preserve the original behavior via cron.daily?
Since the cron script is a conffile, and may have local modifications, I
think it should be left in place, but would take confirmation.  It'd be
possible to perform the migration while still preserving local
modifications, e.g. by having the shipped cron script enable the unit
file, but IMO that would be gross.

If the timer and the cron activity are both enabled, the cron script
will be a no-op.  This is accomplished with the following in the cron
script:

if command -v systemctl > /dev/null 2>&1 &&
   systemctl is-enabled spamassassin-daily-maintenance.timer; then
exit 0
fi

Would you do this a different way?

noah