Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #203037 > unrolled thread

Re: systemd+anacron breaks cron jobs

Back to article view | Back to linux.debian.user

Contents

  Re: systemd+anacron breaks cron jobs Michael Biebl <biebl@debian.org> - 2018-12-05 08:00 +0100
    Re: systemd+anacron breaks cron jobs Michael Biebl <biebl@debian.org> - 2018-12-05 09:00 +0100
      Re: systemd+anacron breaks cron jobs kjonca@fastmail.com (Kamil Jońca) - 2018-12-05 09:20 +0100
        Re: systemd+anacron breaks cron jobs Michael Biebl <biebl@debian.org> - 2018-12-05 10:10 +0100
          Re: systemd+anacron breaks cron jobs kjonca@poczta.onet.pl (Kamil Jońca) - 2018-12-05 10:30 +0100
            Re: systemd+anacron breaks cron jobs Michael Biebl <biebl@debian.org> - 2018-12-05 11:10 +0100
              Re: systemd+anacron breaks cron jobs kjonca@fastmail.com (Kamil Jońca) - 2018-12-05 11:10 +0100
                Re: systemd+anacron breaks cron jobs Michael Biebl <biebl@debian.org> - 2018-12-05 11:10 +0100
                  Re: systemd+anacron breaks cron jobs Michael Biebl <biebl@debian.org> - 2018-12-05 11:20 +0100
                  Re: systemd+anacron breaks cron jobs kjonca@poczta.onet.pl (Kamil Jońca) - 2018-12-05 11:30 +0100
                    Re: systemd+anacron breaks cron jobs Michael Biebl <biebl@debian.org> - 2018-12-05 11:50 +0100
                      Re: systemd+anacron breaks cron jobs kjonca@poczta.onet.pl (Kamil Jońca) - 2018-12-05 12:00 +0100
                        Re: systemd+anacron breaks cron jobs Michael Biebl <biebl@debian.org> - 2018-12-05 12:40 +0100
                          Re: systemd+anacron breaks cron jobs kjonca@poczta.onet.pl (Kamil Jońca) - 2018-12-05 12:50 +0100
                            Re: systemd+anacron breaks cron jobs Cindy-Sue Causey <butterflybytes@gmail.com> - 2018-12-05 19:00 +0100
                              Re: systemd+anacron breaks cron jobs kjonca@poczta.onet.pl (Kamil Jońca) - 2018-12-05 19:20 +0100
                                Re: systemd+anacron breaks cron jobs Cindy-Sue Causey <butterflybytes@gmail.com> - 2018-12-05 19:40 +0100

#203037 — Re: systemd+anacron breaks cron jobs

[Multipart message — attachments visible in raw view] — view raw

> On Mon, 03 Dec 2018, Kamil Jońca wrote:
>> >> Dec 03 00:23:54 alfa systemd[1]: anacron.service: State 'stop-sigterm' timed out. Killing.
>> > See, someone or some script told systemd to stop anacron (or maybe to
>> > stop-and-start/restart it).  THIS is causing the undesired behavior.
>> 
>> Dec 03 00:22:24 alfa systemd[1]: Stopping Run anacron jobs...
>> Dec 03 00:22:24 alfa anacron[8919]: Received SIGUSR1
>> Dec 03 00:23:54 alfa systemd[1]: anacron.service: State 'stop-sigterm' timed out. Killing.
> 
> Looks like something asked systemd to send sigusr1 to anacron, which is
> "clean exit" for anacron.  Since the anacron package told systemd to use
> "killmode mixed", it waits for a while, then proceeds to SIGKILL
> everything in the group because they took too long to die.
> 
> It is a bug, but on anacron, not systemd.  systemd is doing exactly what
> it was (mis)configured to do by the anacron package.
> 
> And something *is* asking anacron to restart or to stop.  Look at your
> log rotation scripts (and also anacron's).

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864213#25
If you drop /lib/udev/rules.d/60-anacron.rules my bet is that the
problem is gone.
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[toc] | [next] | [standalone]

#203040

[Multipart message — attachments visible in raw view] — view raw

Am 05.12.18 um 07:41 schrieb Michael Biebl:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864213#25
> If you drop /lib/udev/rules.d/60-anacron.rules my bet is that the
> problem is gone.

Btw, I'd go as far and say that you can safely drop anacron these days.
A lot of Debian packages which ship a cron job also ship a native
systemd .timer. Such persistent timers handle systems which don't run
24/7 in a much better way.

In your case, I would recommend to use a .timer to start your backup
task. The arch wiki [2] is a good start, or simply take a look at
existing timers on your system:

systemctl cat logrotate.service logrotate.timer

Regards,
Michael

[1]
https://www.freedesktop.org/software/systemd/man/systemd.timer.html#Persistent=
[2] https://wiki.archlinux.org/index.php/Systemd/Timers
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[toc] | [prev] | [next] | [standalone]

#203041

Michael Biebl <biebl@debian.org> writes:

> Am 05.12.18 um 07:41 schrieb Michael Biebl:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864213#25
>> If you drop /lib/udev/rules.d/60-anacron.rules my bet is that the
>> problem is gone.
>
> Btw, I'd go as far and say that you can safely drop anacron these days.

This is only true for "system" tasks.
"User" task aren't started until user logs in. (You should play with
enable-linger, which in turn, can break ALL your "user" units)
This thing stop me from migrating.



KJ

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
Uwolnić słonia !!!

[toc] | [prev] | [next] | [standalone]

#203042

[Multipart message — attachments visible in raw view] — view raw

Am 05.12.18 um 08:54 schrieb Kamil Jońca:
> "User" task aren't started until user logs in. (You should play with
> enable-linger,

I haven't read the full discussion, so I missed the part that you are
apparently using a user crontab.

Just curious: Why are you starting the backup task via a user crontab
and not as a system cron job? Are you only saving the users /home/
directory?


It's correct, that "systemd --user"  is started if you log in, or if you
explicitly enable linger for this user (then it is started during boot).


>  which in turn, can break ALL your "user" units)

I'd be interested to know, what exactly you have in mind here. I'm not
aware of such a breakage.


Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[toc] | [prev] | [next] | [standalone]

#203044

Michael Biebl <biebl@debian.org> writes:

> Am 05.12.18 um 08:54 schrieb Kamil Jońca:
>> "User" task aren't started until user logs in. (You should play with
>> enable-linger,
>
> I haven't read the full discussion, so I missed the part that you are
> apparently using a user crontab.

To clarify things:
1. In original post I described system task which CAN (and sooner or
later will) be migrated to systemd timers.
But then You said that:
2. anacron can be dropped  - which in general is not true, because
systemd cannot provided proper functionality for user units.

> It's correct, that "systemd --user"  is started if you log in, or if you
> explicitly enable linger for this user (then it is started during boot).
>
>
>>  which in turn, can break ALL your "user" units)
>
> I'd be interested to know, what exactly you have in mind here. I'm not
> aware of such a breakage.

For example: I have (--user)
kj-keepassx.service - my own service with keepasx
xscreensaver-monitor.service - my own service which to monitor screensaver

These services should NOT be run withoud graphical login.
But I would run my user timers. How to achieve this?

with cron/anacron I simply put line in my  (ana)crontab.

KJ

-- 
http://wolnelektury.pl/wesprzyj/teraz/
Classical music is the kind we keep thinking will turn into a tune.
		-- Kin Hubbard, "Abe Martin's Sayings"

[toc] | [prev] | [next] | [standalone]

#203046

[Multipart message — attachments visible in raw view] — view raw

Am 05.12.18 um 10:04 schrieb Kamil Jońca:
> Michael Biebl <biebl@debian.org> writes:

>>>  which in turn, can break ALL your "user" units)
>>
>> I'd be interested to know, what exactly you have in mind here. I'm not
>> aware of such a breakage.
> 
> For example: I have (--user)
> kj-keepassx.service - my own service with keepasx
> xscreensaver-monitor.service - my own service which to monitor screensaver
> 
> These services should NOT be run withoud graphical login.

If those services are tied to a X login session, they should not be
started via systemd --user (at least, not yet)

Let me go into a bit more detail.


There is only ever *one* systemd --user instance per user. It is
typically started, the first time you log in and stopped, once there is
no more active login session for a particular user.

If you have multiple active login sessions (say X, and one console login
on tty2), you still have only one systemd --user instance.
If you now logout from X, the systemd --user instance is not stopped,
only if you also logout from tty2.

I hope, you can now see that your kj-keepassx.service is not going to work.

What you really want, is to start that service as part of a X login
session. Those are traditionally handled via
/etc/xdg/autostart and ~/.config/autostart


There are attempts to provide such a XDG autostart equivalent facility
in systemd, by providing a target, which becomes active once a X session
starts and becomes inactive, once the X session ends.
User units which are supposed to be tied to X sessions can then bind to
that target.

See https://blogs.gnome.org/laney/2018/06/26/starting-sessions-with-systemd/
if you want to read a bit more about it.


For the time being, starting a service via a systemd user service which
is bound to the life-time of an X session, is not really supported and I
would recommend you use ~/.config/autostart for it instead.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[toc] | [prev] | [next] | [standalone]

#203047

Michael Biebl <biebl@debian.org> writes:

> Am 05.12.18 um 10:04 schrieb Kamil Jońca:
>> Michael Biebl <biebl@debian.org> writes:
>
>>>>  which in turn, can break ALL your "user" units)
>>>
>>> I'd be interested to know, what exactly you have in mind here. I'm not
>>> aware of such a breakage.
>> 
>> For example: I have (--user)
>> kj-keepassx.service - my own service with keepasx
>> xscreensaver-monitor.service - my own service which to monitor screensaver
>> 
>> These services should NOT be run withoud graphical login.
>
> If those services are tied to a X login session, they should not be
> started via systemd --user (at least, not yet)
>
> Let me go into a bit more detail.
>
>
> There is only ever *one* systemd --user instance per user. It is
> typically started, the first time you log in and stopped, once there is
> no more active login session for a particular user.
>
[...snip...]
I knew all you wrote.
So I my question still is:

How can I:
1. start services only with graphical login and
2. start timers irrespective of graphical login.
KJ



-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
It's a .88 magnum -- it goes through schools.
		-- Danny Vermin

[toc] | [prev] | [next] | [standalone]

#203048

[Multipart message — attachments visible in raw view] — view raw

Am 05.12.18 um 10:47 schrieb Kamil Jońca:
> Michael Biebl <biebl@debian.org> writes:
> 
>> Am 05.12.18 um 10:04 schrieb Kamil Jońca:
>>> Michael Biebl <biebl@debian.org> writes:
>>
>>>>>  which in turn, can break ALL your "user" units)
>>>>
>>>> I'd be interested to know, what exactly you have in mind here. I'm not
>>>> aware of such a breakage.
>>>
>>> For example: I have (--user)
>>> kj-keepassx.service - my own service with keepasx
>>> xscreensaver-monitor.service - my own service which to monitor screensaver
>>>
>>> These services should NOT be run withoud graphical login.
>>
>> If those services are tied to a X login session, they should not be
>> started via systemd --user (at least, not yet)
>>
>> Let me go into a bit more detail.
>>
>>
>> There is only ever *one* systemd --user instance per user. It is
>> typically started, the first time you log in and stopped, once there is
>> no more active login session for a particular user.
>>
> [...snip...]
> I knew all you wrote.
> So I my question still is:
> 
> How can I:
> 1. start services only with graphical login and

You can't. At least not yet. Use ~/.config/autostart
This is what I trying to explain.

> 2. start timers irrespective of graphical login.

If you want them to be started during boot, use enable-linger


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[toc] | [prev] | [next] | [standalone]

#203049

[Multipart message — attachments visible in raw view] — view raw

Am 05.12.18 um 10:49 schrieb Michael Biebl:
> Am 05.12.18 um 10:47 schrieb Kamil Jońca:

>> How can I:
>> 1. start services only with graphical login and
> 
> You can't. At least not yet. Use ~/.config/autostart

Some work has already been done to support graphical-session.target

https://www.freedesktop.org/software/systemd/man/systemd.special.html#graphical-session.target

We are not there yet, though.

A bit more dated is this video from systemd.conf
https://www.youtube.com/watch?v=hq18daxTkLA

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[toc] | [prev] | [next] | [standalone]

#203050

Michael Biebl <biebl@debian.org> writes:

[...]
>
>> 2. start timers irrespective of graphical login.
>
> If you want them to be started during boot, use enable-linger

But 'enable-linger' starts my ALL services, which is not what I want.
I want to start only timers.

KJ

-- 
http://wolnelektury.pl/wesprzyj/teraz/
And the silence came surging softly backwards
When the plunging hooves were gone...
		-- Walter de La Mare, "The Listeners"

[toc] | [prev] | [next] | [standalone]

#203051

[Multipart message — attachments visible in raw view] — view raw

Am 05.12.18 um 11:04 schrieb Kamil Jońca:

> But 'enable-linger' starts my ALL services, which is not what I want.
> I want to start only timers.

Since you can only have one systemd --user instance, this is not possible.
You can't have a systemd --user instance which is started during boot
with only timers.target and a second systemd --user instance which is
started on first login with default.target.


Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[toc] | [prev] | [next] | [standalone]

#203052

Michael Biebl <biebl@debian.org> writes:

> Am 05.12.18 um 11:04 schrieb Kamil Jońca:
>
>> But 'enable-linger' starts my ALL services, which is not what I want.
>> I want to start only timers.
>
> Since you can only have one systemd --user instance, this is not possible.
> You can't have a systemd --user instance which is started during boot
> with only timers.target and a second systemd --user instance which is
> started on first login with default.target.

So I cannot drop (ana)cron :)  EOT

KJ

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
According to the obituary notices, a mean and unimportant person never dies.

[toc] | [prev] | [next] | [standalone]

#203053

[Multipart message — attachments visible in raw view] — view raw

Am 05.12.18 um 11:35 schrieb Kamil Jońca:

> So I cannot drop (ana)cron :)  EOT

With your specific set of requirements, you are most likely best served
by cron (and anacron if your system is not continuously running).

I still don't understand why you need to start your backup task as user
service and during boot instead of just making it a system service, but
that's ok. It's ultimately your decision.

My general remark that anacron is typically not needed anymore, still
stands though (even if it doesn't apply for your specific use case).


Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[toc] | [prev] | [next] | [standalone]

#203054

Michael Biebl <biebl@debian.org> writes:

>
> My general remark that anacron is typically not needed anymore, still
> stands though (even if it doesn't apply for your specific use case).

What is other tool to make USER automated, cyclic tasks?
KJ

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
We totally deny the allegations, and we're trying to identify the allegators.

[toc] | [prev] | [next] | [standalone]

#203055

On 12/5/18, Kamil Jońca <kjonca@poczta.onet.pl> wrote:
> Michael Biebl <biebl@debian.org> writes:
>
>>
>> My general remark that anacron is typically not needed anymore, still
>> stands though (even if it doesn't apply for your specific use case).
>
> What is other tool to make USER automated, cyclic tasks?


I learned of "apt-cache search" a LONG time ago. One of my Top 5 tools
I use A LOT every week. What I did this time was first run "apt-cache
show anacron" because that was in the subject line. That shared
"command scheduler" as an early part of the description so I ran with
that keyword phrase:

+++ BEGIN OUTPUT +++

$ apt-cache search command scheduler
anacron - cron-like program that doesn't go by time
kalarm - alarm message, command and email scheduler
libnet-openssh-parallel-perl - run SSH jobs in parallel
python-axiom - Python object database
task-spooler - personal job scheduler

+++ END OUTPUT +++

Not much but does serve as an example. Kalarm... I think I tried that
as an alarm (then went with alarm-clock-apple instead = LOVE!). I'm
going to go back and look at Kalarm with this thread in mind. I've
seen "cron job" tossed all around but never had enough brain cells
functioning at the same time to actually pursue finding an excuse to
test drive the concept.

True story is that cron jobs always sounded almost too... "daunting".
Kalarm pulling up in this mix, including via its "apt-cache show"
description, just helped throw that #fakeNews impression out the
window. #ThankYou!

Maybe you could try a different, creative combination of other
keywords' "apt-cache search" that you know should work with respect to
anacron. That might lead to more possibilities than what pulled up
above.

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

[toc] | [prev] | [next] | [standalone]

#203056

Cindy-Sue Causey <butterflybytes@gmail.com> writes:

> On 12/5/18, Kamil Jońca <kjonca@poczta.onet.pl> wrote:
>> Michael Biebl <biebl@debian.org> writes:
>>
>>>
>>> My general remark that anacron is typically not needed anymore, still
>>> stands though (even if it doesn't apply for your specific use case).
>>
>> What is other tool to make USER automated, cyclic tasks?
>
>
> I learned of "apt-cache search" a LONG time ago. One of my Top 5 tools
> I use A LOT every week. What I did this time was first run "apt-cache
> show anacron" because that was in the subject line. That shared
> "command scheduler" as an early part of the description so I ran with
> that keyword phrase:
>
> +++ BEGIN OUTPUT +++
>
> $ apt-cache search command scheduler
> anacron - cron-like program that doesn't go by time
> kalarm - alarm message, command and email scheduler
> libnet-openssh-parallel-perl - run SSH jobs in parallel
> python-axiom - Python object database
> task-spooler - personal job scheduler
>
> +++ END OUTPUT +++
>
> Not much but does serve as an example. Kalarm... I think I tried that

Ekhem. kalarm is kde dependent. Whole discussion is about tool which do
not depend on user login ...
The rest of result  is not worth comenting on ...

Yes, I did not search extensively. When (ana)cron exist and they fill my
needs, why should I waste my time?
Recently systemd aggressively try to take more and more jobs, but it is
not quite ready for one-to-one replacement of those[1].

KJ


[1] I am quite happy using systemd as init replacement, but why these folks
want to put there timer, dhcp-client and so on? 
-- 
http://wolnelektury.pl/wesprzyj/teraz/
Normal times may possibly be over forever.

[toc] | [prev] | [next] | [standalone]

#203057

On 12/5/18, Kamil Jońca <kjonca@poczta.onet.pl> wrote:
> Cindy-Sue Causey <butterflybytes@gmail.com> writes:
>
>> On 12/5/18, Kamil Jońca <kjonca@poczta.onet.pl> wrote:
>>> Michael Biebl <biebl@debian.org> writes:
>>>
>>>>
>>>> My general remark that anacron is typically not needed anymore, still
>>>> stands though (even if it doesn't apply for your specific use case).
>>>
>>> What is other tool to make USER automated, cyclic tasks?
>>
>>
>> I learned of "apt-cache search" a LONG time ago. One of my Top 5 tools
>> I use A LOT every week. What I did this time was first run "apt-cache
>> show anacron" because that was in the subject line. That shared
>> "command scheduler" as an early part of the description so I ran with
>> that keyword phrase:
>>
>> +++ BEGIN OUTPUT +++
>>
>> $ apt-cache search command scheduler
>> anacron - cron-like program that doesn't go by time
>> kalarm - alarm message, command and email scheduler
>> libnet-openssh-parallel-perl - run SSH jobs in parallel
>> python-axiom - Python object database
>> task-spooler - personal job scheduler
>>
>> +++ END OUTPUT +++
>>
>> Not much but does serve as an example. Kalarm... I think I tried that
>
> Ekhem. kalarm is kde dependent. Whole discussion is about tool which do
> not depend on user login ...
> The rest of result  is not worth comenting on ...


Sorry about that. I didn't catch that part (I skipped 17 emails and
only read the last one, oops!), but I do fully understand. I just
tried a Kalarm install. It wants to bring about 35MB of other things
in along with. I don't remember non-cron alarm-clock-applet being that
hefty, but it's possible that it would be for someone else depending
on what's already installed on their own setup.


> Yes, I did not search extensively. When (ana)cron exist and they fill my
> needs, why should I waste my time?
> Recently systemd aggressively try to take more and more jobs, but it is
> not quite ready for one-to-one replacement of those[1].
>
> KJ
>
>
> [1] I am quite happy using systemd as init replacement, but why these folks
> want to put there timer, dhcp-client and so on?


You never know. As things progress, maybe your chatter will inspire
someone who's looking for a nice tech class project or something. I
see requests for ideas like that on regular occasion across various
lists.

PS Now that I say that, I see tech posts all the time that are
consistently too timely to the topics brought up here. It's good
stuff. *waving at those folks > I SEE YOU PEEKING!* :D

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web