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
> "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>
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
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
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.
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
>>
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.
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
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
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
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
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.
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:
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
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?
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
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
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
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
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
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
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
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.
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
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
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" ] &&
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:
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
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
42 matches
Mail list logo
