Re: systemd+anacron breaks cron jobs
On 12/5/18, Kamil Jońca wrote: > Cindy-Sue Causey writes: > >> On 12/5/18, Kamil Jońca wrote: >>> Michael Biebl 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 *
Re: systemd+anacron breaks cron jobs
Cindy-Sue Causey writes: > On 12/5/18, Kamil Jońca wrote: >> Michael Biebl 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.
Re: systemd+anacron breaks cron jobs
On 12/5/18, Kamil Jońca wrote: > Michael Biebl 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 *
Re: systemd+anacron breaks cron jobs
Michael Biebl 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.
Re: systemd+anacron breaks cron jobs
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? signature.asc Description: OpenPGP digital signature
Re: systemd+anacron breaks cron jobs
Michael Biebl 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.
Re: systemd+anacron breaks cron jobs
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? signature.asc Description: OpenPGP digital signature
Re: systemd+anacron breaks cron jobs
Michael Biebl 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"
Re: systemd+anacron breaks cron jobs
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? signature.asc Description: OpenPGP digital signature
Re: systemd+anacron breaks cron jobs
Am 05.12.18 um 10:47 schrieb Kamil Jońca: > Michael Biebl writes: > >> Am 05.12.18 um 10:04 schrieb Kamil Jońca: >>> Michael Biebl 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? signature.asc Description: OpenPGP digital signature
Re: systemd+anacron breaks cron jobs
Michael Biebl writes: > Am 05.12.18 um 10:04 schrieb Kamil Jońca: >> Michael Biebl 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
Re: systemd+anacron breaks cron jobs
Am 05.12.18 um 10:04 schrieb Kamil Jońca: > Michael Biebl 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? signature.asc Description: OpenPGP digital signature
Re: systemd+anacron breaks cron jobs
Michael Biebl 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"
Re: systemd+anacron breaks cron jobs
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? signature.asc Description: OpenPGP digital signature
Re: systemd+anacron breaks cron jobs
Michael Biebl 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 !!!
Re: systemd+anacron breaks cron jobs
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? signature.asc Description: OpenPGP digital signature
Re: systemd+anacron breaks cron jobs
Michael Biebl writes: [...] > > 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. kjonca@alfa:~%ls /lib/udev/rules.d/60-anacron.rules ls: cannot access '/lib/udev/rules.d/60-anacron.rules': No such file or directory So what? KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html You can't hug a child with nuclear arms.
Re: systemd+anacron breaks cron jobs
> 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? signature.asc Description: OpenPGP digital signature
Re: systemd+anacron breaks cron jobs?
On Tuesday, December 4, 2018 at 1:40:03 PM UTC+5:30, Kamil Jońca wrote: > Rusi Mody writes: > > Best bet is switch to using systemd timers > > Second question: Why systemd kills my jobs? (Yes I know what parameters > are responsible for this, but why they are configured that way?) I am no expert of systemd. Heck Im not even a noob! Just saying that timers seems to be the systemd way in place of cron/anacron https://unix.stackexchange.com/questions/278564/cron-vs-systemd-timers > > Ekhem. My personal cron entries are called regardles I am logged in or > not. How can I achieve this with systemd "user" timers? The specific answer is (I guess!) to look at persistent/ linger etc options The wider answer maybe: Do you really need to use user units? Especially when you explicitly want their usage dissociated from user sessions?
Re: systemd+anacron breaks cron jobs?
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). > I have NO scripts which kill anacron. IMO it is systemd thing. What happens when the anacron service is stopped/restarted under systemd is different from non-systemd anacron, but that's because the anacron package misconfigured systemd, so it would be a "systemd thing as (mis)configured by the package". But something is triggering that service stop/restart/force-reload (can't tell which from the logs), and it is not systemd. systemd is obeying orders from some other system component. -- Henrique Holschuh
Re: systemd+anacron breaks cron jobs?
Rusi Mody writes: > On Monday, December 3, 2018 at 1:30:07 PM UTC+5:30, Kamil Jońca wrote: >> I have in my /etc/cron.daily some local scripts. >> Some of them can be occassionally time-consuming. >> Recently I found that some of them did not end. >> And what I found: >> 1. as "everybody" knows, in case of anacron presence, system cron jobs >> are delegated to anacron. >> 2. recently in Debian we have anacron.timer which also runs "cron.daily" >>entry. >> 3. there is a timeout in systemd services which cause to kill my jobs :( >> >> So my question is: is it safe to remove/disable anacron timer? > > Best bet is switch to using systemd timers Ekhem. My personal cron entries are called regardles I am logged in or not. How can I achieve this with systemd "user" timers? Second question: Why systemd kills my jobs? (Yes I know what parameters are responsible for this, but why they are configured that way?) KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html The Ancient Doctrine of Mind Over Matter: I don't mind... and you don't matter. -- As revealed to reporter G. Rivera by Swami Havabanana
Re: systemd+anacron breaks cron jobs?
On Monday, December 3, 2018 at 1:30:07 PM UTC+5:30, Kamil Jońca wrote: > I have in my /etc/cron.daily some local scripts. > Some of them can be occassionally time-consuming. > Recently I found that some of them did not end. > And what I found: > 1. as "everybody" knows, in case of anacron presence, system cron jobs > are delegated to anacron. > 2. recently in Debian we have anacron.timer which also runs "cron.daily" >entry. > 3. there is a timeout in systemd services which cause to kill my jobs :( > > So my question is: is it safe to remove/disable anacron timer? Best bet is switch to using systemd timers https://medium.com/horrible-hacks/using-systemd-as-a-better-cron-a4023eea996d https://unix.stackexchange.com/questions/84858/systemd-timer-units-that-mimic-anacron-behaviour
Re: systemd+anacron breaks cron jobs?
Henrique de Moraes Holschuh writes: > On Mon, 03 Dec 2018, Kamil Jońca wrote: >> 1. as "everybody" knows, in case of anacron presence, system cron jobs >> are delegated to anacron. >> 2. recently in Debian we have anacron.timer which also runs "cron.daily" >>entry. >> 3. there is a timeout in systemd services which cause to kill my jobs :( > > Eh, that will only happen if you try to stop the anacron service, > otherwise the timeout would apply to anacron _itself_ failing to start, > not to any of its jobs... > >> 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. Could you, please, interpret these logs (excerpt from "journalctl -u anacron.service" result) Dec 03 00:03:45 alfa systemd[1]: Started Run anacron jobs. Dec 03 00:03:45 alfa anacron[8919]: Anacron 2.3 started on 2018-12-03 Dec 03 00:03:45 alfa anacron[8919]: Will run job `cron.daily' in 5 min. Dec 03 00:03:45 alfa anacron[8919]: Will run job `cron.weekly' in 10 min. Dec 03 00:03:45 alfa anacron[8919]: Jobs will be executed sequentially Dec 03 00:08:45 alfa anacron[8919]: Job `cron.daily' started Dec 03 00:08:45 alfa anacron[9253]: Updated timestamp for job `cron.daily' to 2018-12-03 Dec 03 00:17:55 alfa sudo[14045]: root : TTY=unknown ; PWD=/ ; USER=f4y ; COMMAND=/bin/bash -c /home/kjonca/archive.sh Dec 03 00:17:55 alfa sudo[14045]: pam_unix(sudo:session): session opened for user kjonca by (uid=0) Dec 03 00:17:56 alfa sudo[14045]: pam_unix(sudo:session): session closed for user kjonca Dec 03 00:17:56 alfa sudo[14049]: root : TTY=unknown ; PWD=/ ; USER=news ; COMMAND=/usr/local/lib/news/dumpnews Dec 03 00:17:56 alfa sudo[14049]: pam_unix(sudo:session): session opened for user news by (uid=0) 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. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 8919 (anacron) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 9249 (sh) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 9250 (run-parts) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 9409 (local) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14049 (sudo) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14050 (dumpnews) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14067 (sort) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14068 (tar) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14069 (xz) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Main process exited, code=killed, status=9/KILL Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 9249 (sh) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 9250 (run-parts) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14049 (sudo) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14050 (dumpnews) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14067 (sort) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14068 (tar) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14069 (xz) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Failed with result 'timeout'. Dec 03 00:23:54 alfa systemd[1]: Stopped Run anacron jobs. Dec 03 01:00:02 alfa systemd[1]: Started Run anacron jobs. > > I am not sure what the proper fix would be in this case, depends on what > caused the attempt to stop (or maybe restart) the service. I have NO scripts which kill anacron. IMO it is systemd thing. KJ -- http://wolnelektury.pl/wesprzyj/teraz/ The aim of a joke is not to degrade the human being but to remind him that he is already degraded. -- George Orwell
Re: systemd+anacron breaks cron jobs?
Kamil Jońca wrote: > Here is some journal excerpt: > Dec 03 00:23:54 alfa systemd[1]: anacron.service: State 'stop-sigterm' > timed out. Killing. Dec 03 00:23:54 alfa systemd[1]: anacron.service: > Killing process 8919 (anacron) with signal SIGKILL. Dec 03 00:23:54 alfa > systemd[1]: anacron.service: Killing process 9249 (sh) with signal > SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process > 9250 (run-parts) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: > anacron.service: Killing process 9409 (local) with signal SIGKILL. Dec 03 > 00:23:54 alfa systemd[1]: anacron.service: Killing process 14049 (sudo) > with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: > Killing process 14050 (dumpnews) with signal SIGKILL. Dec 03 00:23:54 alfa > systemd[1]: anacron.service: Killing process 14067 (sort) with signal > SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process > 14068 (tar) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: > anacron.service: Killing process 14069 (xz) with signal SIGKILL. Dec 03 > 00:23:54 alfa systemd[1]: anacron.service: Main process exited, > code=killed, status=9/KILL Dec 03 00:23:54 alfa systemd[1]: > anacron.service: Killing process 9249 (sh) with signal SIGKILL. Dec 03 > 00:23:54 alfa systemd[1]: anacron.service: Killing process 9250 > (run-parts) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: > anacron.service: Killing process 14049 (sudo) with signal SIGKILL. Dec 03 > 00:23:54 alfa systemd[1]: anacron.service: Killing process 14050 > (dumpnews) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: > anacron.service: Killing process 14067 (sort) with signal SIGKILL. Dec 03 > 00:23:54 alfa systemd[1]: anacron.service: Killing process 14068 (tar) > with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: > Killing process 14069 (xz) with signal SIGKILL. Dec 03 00:23:54 alfa > systemd[1]: anacron.service: Failed with result 'timeout'. Looks like systemd is trying to interpret the command from the cronjob and it does not manage to handle it. I do not use systemd, but I read that you need to update scripts to match the systemd logic, so it might be you should rewrite this or other wise tell systemd to ignore it. regards
Re: systemd+anacron breaks cron jobs?
On Mon, 03 Dec 2018, Kamil Jońca wrote: > 1. as "everybody" knows, in case of anacron presence, system cron jobs > are delegated to anacron. > 2. recently in Debian we have anacron.timer which also runs "cron.daily" >entry. > 3. there is a timeout in systemd services which cause to kill my jobs :( Eh, that will only happen if you try to stop the anacron service, otherwise the timeout would apply to anacron _itself_ failing to start, not to any of its jobs... > 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. I am not sure what the proper fix would be in this case, depends on what caused the attempt to stop (or maybe restart) the service. -- Henrique Holschuh
systemd+anacron breaks cron jobs?
I have in my /etc/cron.daily some local scripts. Some of them can be occassionally time-consuming. Recently I found that some of them did not end. And what I found: 1. as "everybody" knows, in case of anacron presence, system cron jobs are delegated to anacron. 2. recently in Debian we have anacron.timer which also runs "cron.daily" entry. 3. there is a timeout in systemd services which cause to kill my jobs :( So my question is: is it safe to remove/disable anacron timer? Here is some journal excerpt: Dec 03 00:23:54 alfa systemd[1]: anacron.service: State 'stop-sigterm' timed out. Killing. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 8919 (anacron) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 9249 (sh) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 9250 (run-parts) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 9409 (local) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14049 (sudo) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14050 (dumpnews) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14067 (sort) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14068 (tar) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14069 (xz) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Main process exited, code=killed, status=9/KILL Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 9249 (sh) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 9250 (run-parts) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14049 (sudo) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14050 (dumpnews) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14067 (sort) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14068 (tar) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Killing process 14069 (xz) with signal SIGKILL. Dec 03 00:23:54 alfa systemd[1]: anacron.service: Failed with result 'timeout'. KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html A rolling disk gathers no MOS.
