Re: Please drop anacron from task-desktop

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Please drop anacron from task-desktop

Holger Wansing-4
[ Forwarding this to -devel ]


Hi,

Laurent Bigonville <[hidden email]> wrote:

> On Mon, 03 Dec 2018 09:44:05 +0100 Michael Biebl <[hidden email]> wrote:
>
> Hello,
>
>  >
>  > anacron was added to the desktop-task a long time ago.
>  > The changelog doesn't mention why it was added, but I assume it was to
>  > support systems which are not running 24/7 and to ensure that cron jobs
>  > have a chance to run.
>  >
>  > Nowadays, we have systemd .timer units, which handle this issue much
>  > nicer. I checked a default desktop installation, and all important cron
>  > jobs have a corresponding .timer unit.
>  > It thus seems safe to drop anacron from task-desktop.
>  >
>
> I'm actually wondering if this is a good idea..
>
> There are lot of other packages installing cronjobs and people, I would
> assume, expect that they will run.
>
> I would personally revert his patch as long as all the cronjobs have not
> a corresponding systemd .timer

Any thoughts on this?

Is there still a broad necessity for anacron?
Are there still many packages, that don't rely on systemd timer units?


Holger




--
Holger Wansing <[hidden email]>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Reply | Threaded
Open this post in threaded view
|

Re: Please drop anacron from task-desktop

Michael Stone-2
On Thu, Mar 07, 2019 at 09:02:23PM +0100, Holger Wansing wrote:
>> I'm actually wondering if this is a good idea..
>>
>> There are lot of other packages installing cronjobs and people, I would
>> assume, expect that they will run.
>>
>> I would personally revert his patch as long as all the cronjobs have not
>> a corresponding systemd .timer
>
>Any thoughts on this?

What's the downside to having anacron there if a .timer supersedes the
cron job?

Reply | Threaded
Open this post in threaded view
|

Re: Please drop anacron from task-desktop

David Bremner
In reply to this post by Holger Wansing-4
Holger Wansing <[hidden email]> writes:
>
> Any thoughts on this?
>
> Is there still a broad necessity for anacron?
> Are there still many packages, that don't rely on systemd timer units?
>

Presumably packages that work without systemd, but still need to
periodic activity?

d

Reply | Threaded
Open this post in threaded view
|

Re: Please drop anacron from task-desktop

Paride Legovini-2
In reply to this post by Michael Stone-2
Michael Stone wrote on 07/03/2019:
> On Thu, Mar 07, 2019 at 09:02:23PM +0100, Holger Wansing wrote:
>>> I'm actually wondering if this is a good idea..
>>>
>>> There are lot of other packages installing cronjobs and people, I would
>>> assume, expect that they will run.

cronjobs run even without anacron, they just don't run
"anac(h)ronistically".

>>> I would personally revert his patch as long as all the cronjobs have not
>>> a corresponding systemd .timer
>>
>> Any thoughts on this?
>
> What's the downside to having anacron there if a .timer supersedes the
> cron job?

Having a useless service running is itself a downside; I second the
removal. I'll also mention that anacron has been orphaned almost one
year ago.

Paride

Reply | Threaded
Open this post in threaded view
|

Re: Please drop anacron from task-desktop

Laurent Bigonville-5

Paride Legovini wrote:

Having a useless service running is itself a downside; I second the
removal. I'll also mention that anacron has been orphaned almost one
year ago.
anacron is AFAICS not running as a service (at least not all the time), it is started by cron (or systemd) every hours and exits just after.

Reply | Threaded
Open this post in threaded view
|

Re: Please drop anacron from task-desktop

Adrian Bunk-3
In reply to this post by Paride Legovini-2
On Thu, Mar 07, 2019 at 10:11:41PM +0100, Paride Legovini wrote:
> Michael Stone wrote on 07/03/2019:
> > On Thu, Mar 07, 2019 at 09:02:23PM +0100, Holger Wansing wrote:
> >>> I'm actually wondering if this is a good idea..
> >>>
> >>> There are lot of other packages installing cronjobs and people, I would
> >>> assume, expect that they will run.
>
> cronjobs run even without anacron, they just don't run
> "anac(h)ronistically".

Which means some won't ever run on a 9 to 5 desktop.

> >>> I would personally revert his patch as long as all the cronjobs have not
> >>> a corresponding systemd .timer
> >>
> >> Any thoughts on this?
> >
> > What's the downside to having anacron there if a .timer supersedes the
> > cron job?
>
> Having a useless service running is itself a downside; I second the
> removal.

Please explain your usage of the word "useless".

The output of "ls /etc/cron.daily" is not empty for me.

> I'll also mention that anacron has been orphaned almost one
> year ago.

I'll also mention that "has been orphaned" does not imply anthing about
the quality of the package.

4 QA uploads fixing 11 bugs in the BTS.
Compared to 1 upload fixing 1 bug in the BTS in the last
3 years when it was non-orphaned.

A sad truth about Debian is that QA-maintained orphaned packages
are often better maintained than many non-orphaned packages.

And anacron is actually a pretty good example for that.

> Paride

cu
Adrian

--

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Reply | Threaded
Open this post in threaded view
|

Re: Please drop anacron from task-desktop

Simon McVittie-7
On Thu, 07 Mar 2019 at 17:07:18 -0400, David Bremner wrote:
> Holger Wansing <[hidden email]> writes:
> > Are there still many packages, that don't rely on systemd timer units?
>
> Presumably packages that work without systemd, but still need to
> periodic activity?

Default installations of Debian boot with systemd, and if a sysadmin
chooses to switch to another init system, it's up to them to replace
its functionality (or at least the parts of its functionality they
want). Needing to install anacron in addition to sysvinit seems
reasonable.

Maybe task-desktop should depend on systemd-sysv | anacron?

On Fri, 08 Mar 2019 at 07:34:23 +0100, Laurent Bigonville wrote:
> anacron is AFAICS not running as a service (at least not all the time), it is
> started by cron (or systemd) every hours and exits just after.

You're right that it isn't a daemon, and isn't running all the time. It
does result in systemd or cron waking up every hour and making noise in
the syslog even if there is nothing to be done, though.

On Fri, 08 Mar 2019 at 10:24:28 +0200, Adrian Bunk wrote:
> The output of "ls /etc/cron.daily" is not empty for me.

That doesn't *necessarily* mean you need anacron, or even cron. Many
cron jobs now have a corresponding systemd timer; if you are running
systemd, the cron job starts, detects that it is unnecessary, and exits,
which is an overly-complicated way to do nothing.

For example, if I understand correctly, anacron was initially added to
the GNOME metapackage (and later to task-desktop) for logrotate, but
/etc/cron.daily/logrotate now starts with:

    # skip in favour of systemd timer
    if [ -d /run/systemd/system ]; then
        exit 0
    fi

In a more opinionated distribution the solution would have been "require
systemd, rely on systemd timers, delete cron jobs, move on", but Debian
still supports non-systemd init as a non-default installation, and
anacron/cron don't have a built-in way to skip particular cron jobs other
than open-coding it in the cron job itself.

Regards,
    smcv

Reply | Threaded
Open this post in threaded view
|

Re: Please drop anacron from task-desktop

Paride Legovini-2
In reply to this post by Adrian Bunk-3
Hello Adrian,

Adrian Bunk wrote on 08/03/2019:

> On Thu, Mar 07, 2019 at 10:11:41PM +0100, Paride Legovini wrote:
>> Michael Stone wrote on 07/03/2019:
>>> On Thu, Mar 07, 2019 at 09:02:23PM +0100, Holger Wansing wrote:
>>>>> I'm actually wondering if this is a good idea..
>>>>>
>>>>> There are lot of other packages installing cronjobs and people, I would
>>>>> assume, expect that they will run.
>>
>> cronjobs run even without anacron, they just don't run
>> "anac(h)ronistically".
>
> Which means some won't ever run on a 9 to 5 desktop.

Right, but idea of removing it from desktop-task began with observing
that in a default desktop install all the important cron jobs also ship
a .timer.

>>>>> I would personally revert his patch as long as all the cronjobs have not
>>>>> a corresponding systemd .timer
>>>>
>>>> Any thoughts on this?
>>>
>>> What's the downside to having anacron there if a .timer supersedes the
>>> cron job?
>>
>> Having a useless service running is itself a downside; I second the
>> removal.
>
> Please explain your usage of the word "useless".
>
> The output of "ls /etc/cron.daily" is not empty for me.

But a few (a good part?) of them will just do nothing if you are using
systemd, e.g.:

if [ -d /run/systemd/system ]; then
    # Skip in favour of systemd timer.
    exit 0
fi

This will happen more and more over time and I think it's the practice
to favor: having three systems to manage the execution of periodic jobs
(systemd timers, cron, anacron) in the default install is IMHO far ideal.

I don't doubt there *are* cases where anacron is useful, but we're just
talking of removing it from desktop-task, not from the archive, after
all. This said, I just wanted to add a data point to the thread, I agree
there is no strong reason for the removal -- but there is no strong
reason for inclusion neither, and I tend to favor simplicity.

>> I'll also mention that anacron has been orphaned almost one
>> year ago.
>
> I'll also mention that "has been orphaned" does not imply anthing about
> the quality of the package.

I know, and thank our QA team. But I think it tells something on the
interest our community has for the package, especially if orphaned for a
long time.

Paride

Reply | Threaded
Open this post in threaded view
|

Re: Please drop anacron from task-desktop

Marc Haber-3
In reply to this post by Michael Stone-2
On Thu, 7 Mar 2019 15:06:16 -0500, Michael Stone <[hidden email]>
wrote:

>On Thu, Mar 07, 2019 at 09:02:23PM +0100, Holger Wansing wrote:
>>> I'm actually wondering if this is a good idea..
>>>
>>> There are lot of other packages installing cronjobs and people, I would
>>> assume, expect that they will run.
>>>
>>> I would personally revert his patch as long as all the cronjobs have not
>>> a corresponding systemd .timer
>>
>>Any thoughts on this?
>
>What's the downside to having anacron there if a .timer supersedes the
>cron job?

.timer units run all in parallel, which causes unpleasant load spikes
which can even be more unpleasant if many VMs are spiking together on
a virtualization host.

That, IMO, makes systemd timer units unsuitable for daily cron jobs,
for example, which should be geared to cause as low a load spike as
possible. There are even some cron jobs that rely on run-parts'
ordering of cron jobs because they depend on each other.

This is unlikely to change since the parallel execution of timer units
is considered a feature by Upstream. <cynism>Maybe the
start-to-finish-time of cron.daily is a benchmark for system speed as
important as boot times are</cynism>.

Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Reply | Threaded
Open this post in threaded view
|

Re: Please drop anacron from task-desktop

Adam Borowski-3
In reply to this post by Simon McVittie-7
On Fri, Mar 08, 2019 at 09:47:34AM +0000, Simon McVittie wrote:

> On Thu, 07 Mar 2019 at 17:07:18 -0400, David Bremner wrote:
> > Holger Wansing <[hidden email]> writes:
> > > Are there still many packages, that don't rely on systemd timer units?
> >
> > Presumably packages that work without systemd, but still need to
> > periodic activity?
>
> Default installations of Debian boot with systemd, and if a sysadmin
> chooses to switch to another init system, it's up to them to replace
> its functionality (or at least the parts of its functionality they
> want). Needing to install anacron in addition to sysvinit seems
> reasonable.

Yeah, but it's not something that should require a manual action --
especially considering that implementing this well is easy.

> Maybe task-desktop should depend on systemd-sysv | anacron?

Right, but with the reversed order.  This might be a bit unobvious, but:
• on all systemd installs, the dependency is moot (no matter the order)
• on non-systemd, your ordering would make apt try to switch inits instead
  of pulling in anacron
• the only case where non-first dependencies are ignored, B-Deps on official
  buildds, doesn't matter for a task package
 
> That doesn't *necessarily* mean you need anacron, or even cron. Many
> cron jobs now have a corresponding systemd timer; if you are running
> systemd, the cron job starts, detects that it is unnecessary, and exits,
> which is an overly-complicated way to do nothing.

Which raises a question: why would we want that redundant systemd timer?
The cron job can serve everyone, timer only systemd users.  Twice the work,
twice as many configurations to test -- for no gain.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour?
⠈⠳⣄⠀⠀⠀⠀

Reply | Threaded
Open this post in threaded view
|

Re: Please drop anacron from task-desktop

Adrian Bunk-3
In reply to this post by Paride Legovini-2
On Fri, Mar 08, 2019 at 11:22:36AM +0100, Paride Legovini wrote:
> Hello Adrian,

Hi Paride,

> Adrian Bunk wrote on 08/03/2019:
> > On Thu, Mar 07, 2019 at 10:11:41PM +0100, Paride Legovini wrote:
>...
> >> Having a useless service running is itself a downside; I second the
> >> removal.
> >
> > Please explain your usage of the word "useless".
> >
> > The output of "ls /etc/cron.daily" is not empty for me.
>
> But a few (a good part?) of them will just do nothing if you are using
> systemd, e.g.:
>
> if [ -d /run/systemd/system ]; then
>     # Skip in favour of systemd timer.
>     exit 0
> fi

on my system 3 out of 14 are doing this.

And e.g. mlocate updating its database also on a desktop/laptop that is
not runnning during the night is not useless and not having this would
be a real downside.

> This will happen more and more over time and I think it's the practice
> to favor:

The praxis to favor is to check the impact instead of blindly removing
functionality.

"happen more and more" means it might never happen 100%,
for that you would need policy making it mandatory first.

Short-term for buster, installing anacron still looks appropriate.

And compared to everything else that is running on our default desktop,
anacron does not create any noticable overhead.

> having three systems to manage the execution of periodic jobs
> (systemd timers, cron, anacron) in the default install is IMHO far ideal.
>...

Calling anacron a separate system is not correct, it works on the normal
cron jobs (ideally this functionality should have been implemented in
cron itself).

> Paride

cu
Adrian

--

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Reply | Threaded
Open this post in threaded view
|

Re: Please drop anacron from task-desktop

Adrian Bunk-3
In reply to this post by Simon McVittie-7
> On Fri, 08 Mar 2019 at 10:24:28 +0200, Adrian Bunk wrote:
> > The output of "ls /etc/cron.daily" is not empty for me.
>
> That doesn't *necessarily* mean you need anacron, or even cron. Many
> cron jobs now have a corresponding systemd timer; if you are running
> systemd, the cron job starts, detects that it is unnecessary, and exits,
> which is an overly-complicated way to do nothing.
>...

many != all

Something will break (like in the mlocate case), and people might only
start noticing when they are doing fresh installs of buster after the
release.

For buster it is too late in the release cycle for sorting this out
properly for all existing daily/weekly/monthly cronjobs.

> Regards,
>     smcv

cu
Adrian

--

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Reply | Threaded
Open this post in threaded view
|

Re: Re: Please drop anacron from task-desktop

Laurent Bigonville-5
In reply to this post by Simon McVittie-7

Simon McVittie wrote:

In a more opinionated distribution the solution would have been "require
systemd, rely on systemd timers, delete cron jobs, move on", but Debian
still supports non-systemd init as a non-default installation, and
anacron/cron don't have a built-in way to skip particular cron jobs other
than open-coding it in the cron job itself.
In the long run that's maybe something we want though. I've opened a bug (#922862) against lintian to emit an (experimental) tag for packages that are providing a cronjob but not a .timer to keep track of this.

An other option might be to use systemd-cron but that's too late now for the upcoming release.

Reply | Threaded
Open this post in threaded view
|

Re: Re: Please drop anacron from task-desktop

Adam Borowski-3
On Fri, Mar 08, 2019 at 02:16:13PM +0100, Laurent Bigonville wrote:

> Simon McVittie wrote:
>
> > In a more opinionated distribution the solution would have been "require
> > systemd, rely on systemd timers, delete cron jobs, move on", but Debian
> > still supports non-systemd init as a non-default installation, and
> > anacron/cron don't have a built-in way to skip particular cron jobs other
> > than open-coding it in the cron job itself.
> In the long run that's maybe something we want though. I've opened a bug
> (#922862) against lintian to emit an (experimental) tag for packages that
> are providing a cronjob but not a .timer to keep track of this.

Shouldn't that be the other way around?  Having .timer but not a cronjob is
a nasty bug, having a cronjob but not .timer is fine (at least unless you
have no cron implementation at all).


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour?
⠈⠳⣄⠀⠀⠀⠀

Reply | Threaded
Open this post in threaded view
|

Re: Please drop anacron from task-desktop

Daniel Reichelt-3
> Shouldn't that be the other way around?  Having .timer but not a cronjob is
> a nasty bug, having a cronjob but not .timer is fine (at least unless you
> have no cron implementation at all).

+1!


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Please drop anacron from task-desktop

Holger Levsen-2
On Fri, Mar 08, 2019 at 01:46:59PM +0000, Daniel Reichelt wrote:
> > Shouldn't that be the other way around?  Having .timer but not a cronjob is
> > a nasty bug, having a cronjob but not .timer is fine (at least unless you
> > have no cron implementation at all).
> +1!

/me yawns. init systemd discussions are sooo 2014. Debian has settled for
a default desktop, a default kernel, a default editor, a default init
system, a default logo, a default filesystem...

And surely we support other, strange and not so strange, choices,
sometimes more and sometimes less, but yawn.


--
tschau,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Please drop anacron from task-desktop

Daniel Reichelt-3
> And surely we support other, strange and not so strange, choices,
> sometimes more and sometimes less, but yawn.

And yet Debian claims to support - pardon - offer init systems other
than systemd for usage.


Either: make a clean cut, kick out everything that has been obsoleted™
by pötterd, thereby putting off (an unqualified number of) users


Or: quit yawning and stick to offering different init systems - with all
the shenannigans that follow.


Sorry for flaming. Then again, yawning is not quite not-flaming as well.


Thx
Daniel


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Please drop anacron from task-desktop

Dimitri John Ledkov-3
In reply to this post by Holger Levsen-2
On Fri, 8 Mar 2019 at 14:48, Holger Levsen <[hidden email]> wrote:

>
> On Fri, Mar 08, 2019 at 01:46:59PM +0000, Daniel Reichelt wrote:
> > > Shouldn't that be the other way around?  Having .timer but not a cronjob is
> > > a nasty bug, having a cronjob but not .timer is fine (at least unless you
> > > have no cron implementation at all).
> > +1!
>
> /me yawns. init systemd discussions are sooo 2014. Debian has settled for
> a default desktop, a default kernel, a default editor, a default init
> system, a default logo, a default filesystem...
>

default buildds to split-usr, thus supporting either merged-usr or
split-usr installations.
default to source-only uploads, because accepting arbitrary built
binaries is odd.

> And surely we support other, strange and not so strange, choices,
> sometimes more and sometimes less, but yawn.
>

Or asking to support things, that in practice are hard and of
questionable benefit - ie. support cross-combinations of building
packages on merged-usr to be then deployed to split-usr. It's like a
new twist on the ultimate buildd from hell. (the test rebuild that
used as dirty chroots as possible to rebuild debian from way back
when). And specifically, since this has never been done before by
anybody and is not at all required to be a supported buildd chroot
configuration. A clean buildd chroot; should not, and need not, be the
same as a runtime chroot/container/installation. It is convenient when
they are, but it is not the best way to achieve the desired results
(clean universal package builds vs great individual runtime
environment).

Specifically about default init, I find it extremely difficult to
justify continous synchronisation between init.d scripts and systemd
units states, whilst the other init is not in use. Imho, it is odd to
continiously update rc*.d symlinks for init.d scripts on systemd
booted machines for things that have native systemd units. Or vice
versa. Switching init is intrusive enough, and imho we should be
dumping the enable/disable state of the systemd units and
creating/removing rc*.d symlinks on an init switch only. It is madness
to support dual boot with either systemd or sysvinit as init
simultaniously at any given time a given installed system.

I guess it is time for me to start drafting GRs to assert our
position, that default choice should work well and should not be
unduly burdened by the non-default, or arbitrary combination of
non-default choices.

--
Regards,

Dimitri.

Reply | Threaded
Open this post in threaded view
|

Re: Please drop anacron from task-desktop

Dimitri John Ledkov-3
In reply to this post by Daniel Reichelt-3
On Fri, 8 Mar 2019 at 15:15, Daniel Reichelt <[hidden email]> wrote:

>
> > And surely we support other, strange and not so strange, choices,
> > sometimes more and sometimes less, but yawn.
>
> And yet Debian claims to support - pardon - offer init systems other
> than systemd for usage.
>
>
> Either: make a clean cut, kick out everything that has been obsoleted™
> by pötterd, thereby putting off (an unqualified number of) users
>
>
> Or: quit yawning and stick to offering different init systems - with all
> the shenannigans that follow.
>
>
> Sorry for flaming. Then again, yawning is not quite not-flaming as well.

Your response is useful. We do support both competing systems. It's
just really is pointless to exec() both implementation of the same
thing, with both of them checking if the other is present, and one of
them bailing.
I hope you can see how that is wasteful on the end-user systems.
Things that we know should not be executed, should not be run.
It's almost as if by default, we should dpkg-redirect out of the way
one thing or the other.
And if anacron has no jobs to run, it should self-remove itself from
cron too. Because when it has no jobs to run, we should not be waking
up for anacron to exit 0 without doing anything ever.
It affects things like battery life, CPU utilization on burstable
cloud instances, etc. It's not free, it has a carbon footprint.

--
Regards,

Dimitri.

Reply | Threaded
Open this post in threaded view
|

Re: Please drop anacron from task-desktop

Russ Allbery-2
In reply to this post by Simon McVittie-7
Simon McVittie <[hidden email]> writes:

> anacron/cron don't have a built-in way to skip particular cron jobs
> other than open-coding it in the cron job itself.

Maybe we should just fix this?  cron is effectively maintained by the
distributions anyway; there hasn't been an official upstream release in
more than twenty years.  This seems like a reasonable feature to add.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>

12