Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Weird Issue - TumbleWeed Runs ALL SystemD Timer Services When Rebooted

8 views
Skip to first unread message

MegaWattz

unread,
Feb 25, 2021, 12:29:01 AM2/25/21
to
Doesn't happen on Debian-derived systems.

BUT, if I reboot a TumbleWeed box it runs ALL the Systemd
timer services. The particular interest is time-layered backups.
They're supposed to run a week to a month apart. Works
perfectly, UNLESS you reboot.

I've tried all the obvious params in the timers, no good
effect. They all have the usual lines for when they
should run.

Any ideas ? Clues ? Rumors ? Incantations ? Sacrifices
to Computus ?


Carlos E.R.

unread,
Feb 25, 2021, 7:36:08 AM2/25/21
to
You could ask on alt.os.linux.suse, or on sup...@lists.opensuse.org
(subscribe first).

--
Cheers, Carlos.

Andreas Kohlbach

unread,
Feb 25, 2021, 10:53:29 AM2/25/21
to
Can't you look instead into cron or anacron?

<https://www.tecmint.com/cron-vs-anacron-schedule-jobs-using-anacron-on-linux/>

Using anacron here and all works like designed.

Must admin that I never dealt with SystemD timers though and might get
it all wrong.
--
Andreas

David W. Hodgins

unread,
Feb 25, 2021, 2:39:57 PM2/25/21
to
On Thu, 25 Feb 2021 10:53:25 -0500, Andreas Kohlbach <a...@spamfence.net> wrote:

> On Thu, 25 Feb 2021 00:28:55 -0500, MegaWattz wrote:
>>
>> Doesn't happen on Debian-derived systems.
>>
>> BUT, if I reboot a TumbleWeed box it runs ALL the Systemd
>> timer services. The particular interest is time-layered backups.
>> They're supposed to run a week to a month apart. Works
>> perfectly, UNLESS you reboot.

According to "man systemd.timer" all units with OnCalendar= directive(s) have
a dependency on time-sync.target to avoid being started before the system clock
has been correctly set.

Since time-sync.target is a static target, is doesn't matter if it's disabled,
however if it has been masked, then the targets that are supposed to wait until
it's finished will go ahead and run, which fits the description of the problem.

What's the output of "systemctl status time-sync.target"?

Regards, Dave Hodgins

--
Change dwho...@nomail.afraid.org to davidw...@teksavvy.com for
email replies.

MegaWattz

unread,
Feb 25, 2021, 11:26:13 PM2/25/21
to
On Thu, 25 Feb 2021 10:53:25 -0500, Andreas Kohlbach
<a...@spamfence.net> wrote:

>On Thu, 25 Feb 2021 00:28:55 -0500, MegaWattz wrote:
>>
>> Doesn't happen on Debian-derived systems.
>>
>> BUT, if I reboot a TumbleWeed box it runs ALL the Systemd
>> timer services. The particular interest is time-layered backups.
>> They're supposed to run a week to a month apart. Works
>> perfectly, UNLESS you reboot.
>>
>> I've tried all the obvious params in the timers, no good
>> effect. They all have the usual lines for when they
>> should run.
>>
>> Any ideas ? Clues ? Rumors ? Incantations ? Sacrifices
>> to Computus ?
>
>Can't you look instead into cron or anacron?
>
><https://www.tecmint.com/cron-vs-anacron-schedule-jobs-using-anacron-on-linux/>

WAS using cron. But again TW (and many OSuse) had a
weirdness - root cron-jobs often didn't run UNLESS you
opened-up the crontab in nano or something and then
saved it again. You didn't have to really change anything
at all, just add and remove a space so it thought it was
saving something new. THEN the cronjobs would work
properly until the next rebooot. This is why I went to timers.

There was some old - five years ? - postings about similar
cron issues on OSuse. CLAIMED it was fixed. Maybe
somebody copied-over some old code ?


>Using anacron here and all works like designed.
>
>Must admin that I never dealt with SystemD timers though and might get
>it all wrong.

They are pretty straightforward actually. You need the timer service
and a service the timer starts up. Only the timer is "active", the
target just sits there being stupid until called. You can set days,
hours, weeks, months, date-ranges and conditions - cron on
steroids.

Anyway, as I said, they work as advertised on Deb systems, so
this is a OSuse thing. I'd RATHER use cron, it's by far the
most well-established solution. Systemd is building a city so
you can have a lightswitch .....

MegaWattz

unread,
Feb 25, 2021, 11:32:14 PM2/25/21
to
Ah HA ! A direction ! A clue !

I'll check on that tomorrow. I may also be possible to throw
in something as simple as a startup delay or dependency
statement to make sure the timer doesn't try anything until
all the clocks are up and set properly.

Could be that on Deb things start running in a slightly different
order, so by the time you hit your timer all the clocks ARE
already up.

Andrei Z.

unread,
Feb 26, 2021, 12:52:03 AM2/26/21
to
Use systemd timers instead of cronjobs - Opensource.com

https://opensource.com/article/20/7/systemd-timers

MegaWattz

unread,
Feb 26, 2021, 2:06:45 AM2/26/21
to
Um ......... I was having problems with root cronjobs so
I switched to systemd timers. Therin was the root of the
question.

BUT, someone suggests that all the system clocks might
not be fully initialized at the time the timer jobs are first
evaluated. There are a few ways to (maybe) get around
that sort of problem. I'm gonna try 'em.

In Debian - where they work as expected - it is likely the
various system items come up in a slightly different order
and the clocks ARE all set right by the time the timer jobs
come up.

Carlos E.R.

unread,
Feb 26, 2021, 8:32:08 AM2/26/21
to
On 26/02/2021 05.26, MegaWattz wrote:
> On Thu, 25 Feb 2021 10:53:25 -0500, Andreas Kohlbach
> <a...@spamfence.net> wrote:
>
>> On Thu, 25 Feb 2021 00:28:55 -0500, MegaWattz wrote:
>>>
>>> Doesn't happen on Debian-derived systems.
>>>
>>> BUT, if I reboot a TumbleWeed box it runs ALL the Systemd
>>> timer services. The particular interest is time-layered backups.
>>> They're supposed to run a week to a month apart. Works
>>> perfectly, UNLESS you reboot.
>>>
>>> I've tried all the obvious params in the timers, no good
>>> effect. They all have the usual lines for when they
>>> should run.
>>>
>>> Any ideas ? Clues ? Rumors ? Incantations ? Sacrifices
>>> to Computus ?
>>
>> Can't you look instead into cron or anacron?
>>
>> <https://www.tecmint.com/cron-vs-anacron-schedule-jobs-using-anacron-on-linux/>
>
> WAS using cron. But again TW (and many OSuse) had a
> weirdness - root cron-jobs often didn't run UNLESS you
> opened-up the crontab in nano or something and then
> saved it again. You didn't have to really change anything
> at all, just add and remove a space so it thought it was
> saving something new. THEN the cronjobs would work
> properly until the next rebooot. This is why I went to timers.

I have never seen that :-o

But then, I don't use TW, but Leap.

--
Cheers, Carlos.

MegaWattz

unread,
Feb 26, 2021, 10:43:33 PM2/26/21
to
Mystery solved - systemd anyway. I had made those timer jobs
using a template which included the "Requires" line. For some
reason my timer calls another service which actually runs what
you want - guess I was thinking "more control". In any case,
when it the timer sees "Requires" it RUNS that service even
though it was set as disabled.

Had tried a number of things, the "Persistent" param and
eliminating various unnecessary lines from the targeted
service, but "Requires" was it. So ubiquitous that I looked
but did not see.

Anyway, no "Requires", service type set to "Oneshot", all
is well.

As for root cron, NO idea - but now I can just go around it.

As for systemd timers, simplicity is the watchword.

0 new messages