Unable to disable anacron

Hello! I’m Dom. I’m new here, came from Archlinux.

This issue I mentioned also on Arch, but here, too.

I’m unable to prevent anacron from running.

  • first I read the man page → added
$ cat /etc/cron.hourly/jobs.deny 
0anacron

→ cron-jobs still running randomly when I resume my computer

  • changed
$ cat /etc/anacrontab 
# /etc/anacrontab: configuration file for anacron

# See anacron(8) and anacrontab(5) for details.

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=2-3

#period in days   delay in minutes   job-identifier   command
#1	5	cron.daily		nice run-parts /etc/cron.daily
#7	25	cron.weekly		nice run-parts /etc/cron.weekly
#@monthly 45	cron.monthly		nice run-parts /etc/cron.monthly

→ cron-jobs still running randomly when I resume my computer

  • next I did chmod -x /etc/cron.horly/0anacron for on-purpose-failure it

→ cron-jobs still running randomly when I resume my computer

Now I’m out of Ideas… I want my jobs only to run as set in the crontab or they must not run at all. No “Random-delayed-running” desired!

Any Ideas of yours, I could try?

Welcome to the forum! :wink:

If you’re going to be powering down your computer and/or hibernating it, then you need to have anacron running, because anacron exists specifically so as to execute maintenance tasks that were scheduled to run when the system was shut down or hibernated.

Ergo, disabling anacron would be A Very Bad Idea™, and it will lead to breakage in the long term. And then you are going to come to us for helping you fix it again. :stuck_out_tongue:

That’s not how things work in a systemd-based distribution. systemd itself has various timers that execute things at scheduled intervals ─ thereby replacing the traditional cron in sysvinit-based systems, although it’s still compatible with that ─ and it’ll make sure that those jobs are executed at the next boot if the system wasn’t running when the jobs were scheduled to run.

Keep your computer running 24/7 and only reboot after an update. :stuck_out_tongue:

1 Like

Thanks for the welcom, Aragorn.

Sorry, but your post was much but not helpful.

Source: man page 5 of /etc/anacrontab


In other words: It is designated to be possible to be disabled. As far as I saw there were only the crontabs I set up, none else.

I understand, what for anacron was designed, but this behaviour is generating more problems as being a solution. As I said: the jobs MUST NOT run but at the times I defined within the crontab. And jobs which I defined and may run at other times don’t have problems, if the don’t run that often.

So I came to the following question:
Which maintenance tasks are you talking about? And where may these be defined, especially because the configurations for cron and anacron are by default, as far as I saw, except my own changes.

A few examples…:

  1. Running updatedb for updating the index of filenames, which you can use with locate in order to quickly find a particular file or set of files based upon a string in their name.

  2. Updating the database of man pages ─ manual pages for shell commands and system calls.

  3. Related to the above, updating the whatis database, which helps you choose the right command for a job.

  4. Rotating the system logs, so that they won’t fill up your drive.

  5. Trimming your SSD (if applicable).

  6. Verifying the integrity of your system’s user accounts and their passwords.

  7. Cleaning up temporary files.

  8. Cleaning out the pamac cache.

  9. Updating the pamac mirror list.

  10. Possibly other periodic maintenance jobs, depending on what you’ve got installed on your system.

systemd timers.

And this maintenance tasks rely on anacron, without adding anything to the crontab or anacrontab?!
This is very inconspicuous!

I understood anacron is part of cronie, which handles crontab in first place and uses anacrontab to run asynchronously (especially in the case you turn off your computer, of course).
Why is systemd (or Manjaro Linux?) relying on anything I can decide to install or not to install for important tasks? That makes no sense to me.

Furthermore systemd has its own chronological jobs ( .timer files), which work independent form cron, and also asynchronous timing - at least it is suggested in the header of the Archiwiki:

Source: systemd/Timers (wiki.archlinux.org/title/Systemd/Timers)


Please help me understand how it would work asynchronously if I wouldn’t have installed cronie at all?
At least I want to understand how this works, without adding anything to the anacrontab or crontab.

Look, I’m not going to claim that I understand all of the relationships between these different components. This is my first systemd-based distribution, and I don’t tend to mess with things I don’t fully understand yet.

But at the same time, I also don’t understand your obsession with running things only when you specify it and not allowing them to be run if the machine wasn’t up when those tasks were scheduled. You have also not provided any reason for your specific requirement.

If you don’t like cronie or anacron, then just uninstall the package, or if that is not possible for whatever reason, remove the execute permission on /usr/bin/anacron. But then that execute permission may get restored again upon the next system update.

sudo chmod 644 /usr/bin/anacron

Disabling it by removing its execute permission is a perverse thing to do, but it’s your system, and like I said, you’re not specifying why you don’t want anacron running, other than that you don’t want that.

You’re right, I missed it:
The jobs I want to run, mostly run ten to 15 minutes.
So I said in crontab

00      20-22           *       *       1       <cmd1>
00      17-22           *       *       2-5     <cmd1>
00      *               *       *       6-7     <cmd1>
00      9-11,14-16,0-5  *       *       1-5     <cmd1>

Next: I get up at the morning at 6:30, and before I leave for work I check my emails at round about 7 o’clock. This is at maximum 5 minutes. And one minute after resuming the machine (form suspend) it starts <cmd1>. Let’s say I resumed my machine at 7:00, the anacron(?) started <cmd1> at 7:02.
I finished my mails at 7:04 and need to head out to work, but can’t suspend the machine again, because the jobs are still running, and let me make waiting until 7:17, when it finished.
The last line is not fully in use, depending on if I’ve to work this day or I don’t. If I’ve to work I’m sleeping form 22:45 to 6:30 and work from (including leaving from my house) 7:05 to 17:20 .

My first thought was: Did I accidentally schedule it at 7 o’clock, too?
And see above: I didn’t!
There’s a time gap between five o’clock to nine o’clock.

This was an actual occurrence and was the day, when I learned about anacron first time.
The times where set pretty accurate for my daily live and work plans. But this smooth procedure is interrupted through anacron’s randomly running - this makes me very sad.


Turn around - let's say I've a day without work: I go to sleep, when I'm tired, maybe at 1 o'clock. (I know, this are running times, so I prepare for bed and then the jobs are done, too. I'm back my computer at 8:35. It would be okay, anacron does it's job, but here I'd still prefer it runs at 9 o'clock, because I'll be at the machine, for sure.


Frankly speaking: When I'm at work or sleeping, I don't want the jobs to run - also not afterwards, as "missed jobs", because it's more interrupting than useful. I hope my English was possible to understand. ^^'

I’ll consider the chmod method, and will add this to my update procedure, if I’m going to use it.

Anacron is provided by the cronie package which you could uninstall and replace your custom cron jobs by systemd-timers.
They have an option to not run the appropriate service at the next available time.

Yes, I know. It’s written in the manpages. And also as I mentioned in a former post: It is NOT preventing it from running anyway.

You scheduled cron jobs not systemd-timers. Your linked wiki should provide the correct information: systemd/Timers - ArchWiki
Don’t set the Persistent=true and it should not run asynchronously.

This may be. But I don’t see sense in the effort switching it to systemd, while cronie basically does what I whish it to do.

The problem actually is this:
“In case you want to disable Anacron, add a line with 0anacron which is the name of the script running the Anacron into the /etc/cron.hourly/jobs.deny file.” (Source: Manpage 5 for anacrontab)
But even if I do what the manpage says: The jobs I set up in crontab still run asynchronously.

I already renamed the anacron binary - having the cron jobs still running asynchronously…

Is using an different timing service the only solution?

I switched to systemd. I set Persistent=false. And it just started at 9:11 o’clock, when I woke my computer from suspend. Why is it still running asynchronously?!

Edit: It seems not to be triggered through the .timer - no corresponding line for execution request in the .timer journalctl. But no other unit reports for this start… I’m going nuts… -.-

When I run anacron -s -n -d -f which should run all jobs, I only receive the output of running daily, weekly, and monthly.
Your jobs shouldn’t be affected by anacron anyway.

I have tested this with a simple cron job (appending the current date to a file):
*/10 * * * * /usr/bin/bash -c "echo $(date) | tee -a /root/tmpcron.log"

It is only run every 10 minutes and not anytime after hibernation.

I wish I could say this, too.

Here are my files and logs. I think they speak for themself…
The only thing I changed was the name, until I felt comfortable with it and today the ExecStartPre entry, to reduce it at least to nearly full hours. But (this is usually not enough, as you can see for my OnCalendar entries…
Please note the execution times, especially for the .timers log. (e.g. 21:10:39 (right after ending suspend))
Or of the .service log: 07:44:00, while 5…9:00:00 no execution is scheduled at all for Mondays…

So: If you see any mistakes, which caused it to run it asynchronously, let me know.

myjob.service
[Unit]
Description=MyJob execution
#For MyJob scheduler

[Service]
Type=oneshot
ExecStartPre=bash -c 'if [ "$(date +%%M)" -lt 2 ] ; then true ; else false ; fi'	# This is new since today
ExecStart=+/root/scripts/MyJob.sh

myjob.timer
[Unit]
Description=Schedule for MyJob
#WITHOUT asynchronously execution

[Timer]
#OnCalendar=Mon *-*-* 20..22:00:00

#OnCalendar=Tue *-*-* 19..22:00:00

OnCalendar=Mon..Fri 17..22:00:00

OnCalendar=Sat,Sun *-*-* *:00:00

#OnCalendar=Mon..Wed,Fri *-*-* 7..11:00:00

#OnCalendar=Thu *-*-* 13..16:00:00

#OnCalendar=Mon..Fri *-*-* 7..11:00:00

OnCalendar=Mon..Fri 9..11,14..16,0..5:00:00

# Vacation
#OnCalendar=*-*-* *:00:00

[Install]
WantedBy=timers.target

journalctl -u myjob.timer
-- Journal begins at Sat 2021-07-17 23:10:23 CEST, ends at Tue 2021-08-10 20:04:44 CEST. --
Aug 09 18:08:10 citadel systemd[1]: Starting MyJob execution file (for timer)...
Aug 09 18:23:18 citadel systemd[1]: myjob.service: Deactivated successfully.
Aug 09 18:23:18 citadel systemd[1]: Finished MyJob execution file (for timer).
Aug 09 18:23:18 citadel systemd[1]: myjob.service: Consumed 2min 36.218s CPU time.
Aug 09 19:00:01 citadel systemd[1]: Starting MyJob execution...
Aug 09 19:00:12 citadel systemd[1]: myjob.service: Deactivated successfully.
Aug 09 19:00:12 citadel systemd[1]: Finished MyJob execution.
Aug 09 20:00:01 citadel systemd[1]: Starting MyJob execution...
Aug 09 20:00:12 citadel systemd[1]: myjob.service: Deactivated successfully.
Aug 09 20:00:12 citadel systemd[1]: Finished MyJob execution.
Aug 09 21:10:39 citadel systemd[1]: Starting MyJob execution...
Aug 09 21:23:05 citadel systemd[1]: myjob.service: Deactivated successfully.
Aug 09 21:23:05 citadel systemd[1]: Finished MyJob execution.
Aug 09 21:23:05 citadel systemd[1]: myjob.service: Consumed 1min 54.390s CPU time.

journalctl -u myjob.service
-- Boot 426585dafa434ae39515d981d8768f50 --
Aug 09 22:46:50 citadel systemd[1]: Starting MyJob execution...
Aug 09 22:46:54 citadel systemd[1]: myjob.service: Deactivated successfully.
Aug 09 22:46:54 citadel systemd[1]: Finished MyJob execution.
Aug 10 07:07:13 citadel systemd[1]: Starting MyJob execution...
Aug 10 07:44:00 citadel systemd[1]: Finished MyJob execution.
Aug 10 07:44:58 citadel systemd[1]: myjob.service: Deactivated successfully.
Aug 10 07:44:58 citadel systemd[1]: Stopped MyJob execution.
Aug 10 07:44:58 citadel systemd[1]: myjob.service: Consumed 2min 36.035s CPU time.
Aug 10 17:51:32 citadel systemd[1]: /etc/systemd/system/myjob.service:7: Failed to resolve unit specifiers in +%M): Invalid slot
Aug 10 17:51:32 citadel systemd[1]: myjob.service: Unit configuration has fatal error, unit will not be started.
Aug 10 18:02:16 citadel systemd[1]: /etc/systemd/system/myjob.service:7: Failed to resolve unit specifiers in $(date +%M): Invalid slot
Aug 10 18:02:16 citadel systemd[1]: myjob.service: Unit configuration has fatal error, unit will not be started.
Aug 10 18:02:36 citadel systemd[1]: /etc/systemd/system/myjob.service:7: Ignoring unknown escape sequences: "$(date +\%M)"
Aug 10 18:02:36 citadel systemd[1]: /etc/systemd/system/myjob.service:7: Failed to resolve unit specifiers in $(date +\%M): Invalid slot
Aug 10 18:02:36 citadel systemd[1]: myjob.service: Unit configuration has fatal error, unit will not be started.
Aug 10 18:02:55 citadel systemd[1]: Starting MyJob execution...
Aug 10 18:02:55 citadel systemd[28999]: myjob.service: Failed to locate executable if: No such file or directory
Aug 10 18:02:55 citadel systemd[28999]: myjob.service: Failed at step EXEC spawning if: No such file or directory
Aug 10 18:02:55 citadel systemd[1]: myjob.service: Control process exited, code=exited, status=203/EXEC
Aug 10 18:02:55 citadel systemd[1]: myjob.service: Failed with result 'exit-code'.
Aug 10 18:02:55 citadel systemd[1]: Failed to start MyJob execution.
Aug 10 18:04:43 citadel systemd[1]: Starting MyJob execution...
Aug 10 18:04:43 citadel systemd[29625]: myjob.service: Failed to locate executable if: No such file or directory
Aug 10 18:04:43 citadel systemd[29625]: myjob.service: Failed at step EXEC spawning if: No such file or directory
Aug 10 18:04:43 citadel systemd[1]: myjob.service: Control process exited, code=exited, status=203/EXEC
Aug 10 18:04:43 citadel systemd[1]: myjob.service: Failed with result 'exit-code'.
Aug 10 18:04:43 citadel systemd[1]: Failed to start MyJob execution.
Aug 10 19:25:06 citadel systemd[1]: /etc/systemd/system/myjob.service:7: Failed to resolve unit specifiers in $(date +%%%M): Invalid slot
Aug 10 19:25:06 citadel systemd[1]: myjob.service: Unit configuration has fatal error, unit will not be started.
Aug 10 19:26:08 citadel systemd[1]: Starting MyJob execution...
Aug 10 19:26:08 citadel systemd[31045]: myjob.service: Failed to locate executable if: No such file or directory
Aug 10 19:26:08 citadel systemd[31045]: myjob.service: Failed at step EXEC spawning if: No such file or directory
Aug 10 19:26:08 citadel systemd[1]: myjob.service: Control process exited, code=exited, status=203/EXEC
Aug 10 19:26:08 citadel systemd[1]: myjob.service: Failed with result 'exit-code'.
Aug 10 19:26:08 citadel systemd[1]: Failed to start MyJob execution.
Aug 10 19:26:24 citadel systemd[1]: /etc/systemd/system/myjob.service:7: Failed to resolve unit specifiers in $(date +%%%M): Invalid slot
Aug 10 19:26:24 citadel systemd[1]: myjob.service: Unit configuration has fatal error, unit will not be started.
Aug 10 19:27:04 citadel systemd[31497]: myjob.service: Failed to locate executable if: No such file or directory
Aug 10 19:27:04 citadel systemd[1]: Starting MyJob execution...
Aug 10 19:27:04 citadel systemd[31497]: myjob.service: Failed at step EXEC spawning if: No such file or directory
Aug 10 19:27:04 citadel systemd[1]: myjob.service: Control process exited, code=exited, status=203/EXEC
Aug 10 19:27:04 citadel systemd[1]: myjob.service: Failed with result 'exit-code'.
Aug 10 19:27:04 citadel systemd[1]: Failed to start MyJob execution.
Aug 10 19:27:33 citadel systemd[1]: Starting MyJob execution...
Aug 10 19:27:33 citadel systemd[31705]: myjob.service: Failed to locate executable if: No such file or directory
Aug 10 19:27:33 citadel systemd[31705]: myjob.service: Failed at step EXEC spawning if: No such file or directory
Aug 10 19:27:33 citadel systemd[1]: myjob.service: Control process exited, code=exited, status=203/EXEC
Aug 10 19:27:33 citadel systemd[1]: myjob.service: Failed with result 'exit-code'.
Aug 10 19:27:33 citadel systemd[1]: Failed to start MyJob execution.
Aug 10 19:30:57 citadel systemd[32827]: myjob.service: Failed to locate executable if: No such file or directory
Aug 10 19:30:57 citadel systemd[32827]: myjob.service: Failed at step EXEC spawning if: No such file or directory
Aug 10 19:30:57 citadel systemd[1]: Starting MyJob execution...
Aug 10 19:30:57 citadel systemd[1]: myjob.service: Control process exited, code=exited, status=203/EXEC
Aug 10 19:30:57 citadel systemd[1]: myjob.service: Failed with result 'exit-code'.
Aug 10 19:30:57 citadel systemd[1]: Failed to start MyJob execution.
Aug 10 19:31:33 citadel systemd[1]: Starting MyJob execution...
Aug 10 19:31:33 citadel systemd[33029]: myjob.service: Failed to locate executable if: No such file or directory
Aug 10 19:31:33 citadel systemd[33029]: myjob.service: Failed at step EXEC spawning if: No such file or directory
Aug 10 19:31:33 citadel systemd[1]: myjob.service: Control process exited, code=exited, status=203/EXEC
Aug 10 19:31:33 citadel systemd[1]: myjob.service: Failed with result 'exit-code'.
Aug 10 19:31:33 citadel systemd[1]: Failed to start MyJob execution.
Aug 10 19:31:53 citadel systemd[1]: Starting MyJob execution...
Aug 10 19:31:53 citadel systemd[33141]: myjob.service: Failed to locate executable if: No such file or directory
Aug 10 19:31:53 citadel systemd[33141]: myjob.service: Failed at step EXEC spawning if: No such file or directory
Aug 10 19:31:53 citadel systemd[1]: myjob.service: Control process exited, code=exited, status=203/EXEC
Aug 10 19:31:53 citadel systemd[1]: myjob.service: Failed with result 'exit-code'.
Aug 10 19:31:53 citadel systemd[1]: Failed to start MyJob execution.
Aug 10 19:32:01 citadel systemd[1]: Starting MyJob execution...
Aug 10 19:32:01 citadel systemd[33214]: myjob.service: Failed to locate executable if: No such file or directory
Aug 10 19:32:01 citadel systemd[33214]: myjob.service: Failed at step EXEC spawning if: No such file or directory
Aug 10 19:32:01 citadel systemd[1]: myjob.service: Control process exited, code=exited, status=203/EXEC
Aug 10 19:32:01 citadel systemd[1]: myjob.service: Failed with result 'exit-code'.
Aug 10 19:32:01 citadel systemd[1]: Failed to start MyJob execution.
Aug 10 19:32:18 citadel systemd[33314]: myjob.service: Failed to locate executable if: No such file or directory
Aug 10 19:32:18 citadel systemd[33314]: myjob.service: Failed at step EXEC spawning if: No such file or directory
Aug 10 19:32:18 citadel systemd[1]: Starting MyJob execution...
Aug 10 19:32:18 citadel systemd[1]: myjob.service: Control process exited, code=exited, status=203/EXEC
Aug 10 19:32:18 citadel systemd[1]: myjob.service: Failed with result 'exit-code'.
Aug 10 19:32:18 citadel systemd[1]: Failed to start MyJob execution.
Aug 10 19:35:29 citadel systemd[1]: Starting MyJob execution...
Aug 10 19:35:29 citadel systemd[1]: myjob.service: Control process exited, code=exited, status=1/FAILURE
Aug 10 19:35:29 citadel systemd[1]: myjob.service: Failed with result 'exit-code'.
Aug 10 19:35:29 citadel systemd[1]: Failed to start MyJob execution.
Aug 10 19:36:06 citadel systemd[1]: Starting MyJob execution...
Aug 10 19:53:59 citadel systemd[1]: myjob.service: Deactivated successfully.
Aug 10 19:53:59 citadel systemd[1]: Finished MyJob execution.
Aug 10 19:53:59 citadel systemd[1]: myjob.service: Consumed 2min 18.386s CPU time.
Aug 10 20:00:01 citadel systemd[1]: Starting MyJob execution...
Aug 10 20:00:06 citadel systemd[1]: myjob.service: Deactivated successfully.
Aug 10 20:00:06 citadel systemd[1]: Finished MyJob execution.
-- Journal begins at Sat 2021-07-17 23:10:23 CEST, ends at Tue 2021-08-10 20:04:44 CEST. --
Aug 09 17:06:35 citadel systemd[1]: /etc/systemd/system/myjob.timer:6: Unknown key name 'OnCalender' in section 'Timer', ignoring.
Aug 09 17:06:35 citadel systemd[1]: /etc/systemd/system/myjob.timer:12: Unknown key name 'OnCalender' in section 'Timer', ignoring.
Aug 09 17:06:35 citadel systemd[1]: /etc/systemd/system/myjob.timer:15: Unknown key name 'OnCalender' in section 'Timer', ignoring.
Aug 09 17:06:35 citadel systemd[1]: /etc/systemd/system/myjob.timer:27: Unknown key name 'OnCalender' in section 'Timer', ignoring.
Aug 09 17:06:35 citadel systemd[1]: myjob.timer: Timer unit lacks value setting. Refusing.
Aug 09 17:07:14 citadel systemd[1]: /etc/systemd/system/myjob.timer:12: Failed to parse calendar specification, ignoring: Tue..Fri 17-22:00:00
Aug 09 18:03:59 citadel systemd[1]: Started Timer for myjob WITHOUT asynchronously execution.
Aug 09 18:04:59 citadel systemd[1]: myjob.timer: Deactivated successfully.
Aug 09 18:04:59 citadel systemd[1]: Stopped Timer for myjob WITHOUT asynchronously execution.
Aug 09 18:04:59 citadel systemd[1]: Stopping Timer for myjob WITHOUT asynchronously execution.
Aug 09 18:04:59 citadel systemd[1]: Started Timer for myjob WITHOUT asynchronously execution.
Aug 09 18:05:29 citadel systemd[1]: myjob.timer: Deactivated successfully.
Aug 09 18:05:29 citadel systemd[1]: Stopped Timer for myjob WITHOUT asynchronously execution.
Aug 09 18:05:29 citadel systemd[1]: Stopping Timer for myjob WITHOUT asynchronously execution.
Aug 09 18:05:29 citadel systemd[1]: Started Timer for myjob WITHOUT asynchronously execution.
Aug 09 18:31:24 citadel systemd[1]: myjob.timer: Deactivated successfully.
Aug 09 18:31:24 citadel systemd[1]: Stopped Timer for MyJob WITHOUT asynchronously execution.
Aug 09 18:31:24 citadel systemd[1]: Stopping Timer for MyJob WITHOUT asynchronously execution.
Aug 09 18:31:24 citadel systemd[1]: Started Timer for MyJob WITHOUT asynchronously execution.
Aug 09 18:33:27 citadel systemd[1]: myjob.timer: Deactivated successfully.
Aug 09 18:33:27 citadel systemd[1]: Stopped Schedule for MyJob.
Aug 09 18:33:27 citadel systemd[1]: Stopping Schedule for MyJob.
Aug 09 18:33:27 citadel systemd[1]: Started Schedule for MyJob.
Aug 09 21:26:32 citadel systemd[1]: myjob.timer: Deactivated successfully.
Aug 09 21:26:32 citadel systemd[1]: Stopped Schedule for MyJob.
-- Boot 087af4a7c99c4f15bbec4189ed8663ac --
Aug 09 21:26:38 citadel systemd[1]: Started Schedule for MyJob.
Aug 09 21:30:08 citadel systemd[1]: myjob.timer: Deactivated successfully.
Aug 09 21:30:08 citadel systemd[1]: Stopped Schedule for MyJob.

The answering didn’t work properly, sorry.

Could you clear up all errors first? I think some entries might not be correct. (E.g. “OnCalender”)

With systemctl list-timers you can see when they are scheduled, and with systemd-analyze you can verify your time strings.

Yes, on first setup I had some issues, but the file I posted before (myjob.timer) works. (At least it triggers myjob.service , but more often as I want it to, of course. (Or maybe not called by the timer, but any other unit? I have no idea - same problem as I had on crontab…)

In other words: The syntax error is cleared since I set this file up.

$ systemd-analyze 
Startup finished in 1.802s (kernel) + 6.979s (userspace) = 8.782s 
graphical.target reached after 6.575s in userspace
$ systemctl list-timers
NEXT                         LEFT                LAST                         PASSED      UNIT                         ACTIVATES
Tue 2021-08-10 22:00:00 CEST 30min left          Tue 2021-08-10 21:00:01 CEST 29min ago   myjob.timer                  myjob.service
Wed 2021-08-11 00:00:00 CEST 2h 30min left       Tue 2021-08-10 07:07:13 CEST 14h ago     logrotate.timer              logrotate.service
Wed 2021-08-11 00:00:00 CEST 2h 30min left       Tue 2021-08-10 07:07:13 CEST 14h ago     man-db.timer                 man-db.service
Wed 2021-08-11 00:00:00 CEST 2h 30min left       Tue 2021-08-10 07:07:13 CEST 14h ago     pkgfile-update.timer         pkgfile-update.service
Wed 2021-08-11 00:00:00 CEST 2h 30min left       Tue 2021-08-10 07:07:13 CEST 14h ago     shadow.timer                 shadow.service
Wed 2021-08-11 09:22:18 CEST 11h left            Tue 2021-08-10 19:25:06 CEST 2h 3min ago updatedb.timer               updatedb.service
Wed 2021-08-11 18:17:55 CEST 20h left            Tue 2021-08-10 07:16:54 CEST 14h ago     systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Thu 2021-08-12 16:01:18 CEST 1 day 18h left      Thu 2021-08-05 14:46:06 CEST 5 days ago  pamac-mirrorlist.timer       pamac-mirrorlist.service
Sat 2021-09-04 15:00:00 CEST 3 weeks 3 days left Sat 2021-08-07 15:00:01 CEST 3 days ago  pamac-cleancache.timer       pamac-cleancache.service

9 timers listed.
Pass --all to see loaded but inactive timers, too.

Could it be a problem of
Implicit Dependencies or Default Dependencies of the timer unit?

Until now I was unable to find the issue, why it is running even when it shouldn’t be. But I created a workaround.

I’m going to try to reproduce the issue into an VM and find the issue while exact tracking of my changes to the machine.
However as I told I got up a workaround:

First see my configuration files, I’ll explain below.

myjob.service

[Unit]
Description=MyJob execution

[Service]
Type=oneshot
ExecStartPre=bash -c 'lckf="/run/lock/myjob.lck" ; if [ "$(date --date="$(uptime -s)" +%%s)" -lt "$(date --date=-2-minutes +%%s)" ] || [ -e "$lckf" ] ; then true ; else touch "$lckf" ; false ; fi'
ExecStart=/root/scripts/MyJob.sh
ExecStartPost=bash -c 'lckf="/run/lock/myjob.lck" ; if [ -e "$lckf" ] ; then rm -f "$lckf" ; fi'

myjob.timer

[Unit]
Description=Schedule for MyJob

[Timer]
#OnCalendar=Mon *-*-* 20..22:00:00
#OnCalendar=Tue *-*-* 19..22:00:00
OnCalendar=Mon..Fri 17..22:00:00
OnCalendar=Sat,Sun *-*-* *:00:00

#OnCalendar=Mon..Wed,Fri *-*-* 7..11:00:00
#OnCalendar=Thu *-*-* 13..16:00:00
#OnCalendar=Mon..Fri *-*-* 7..11:00:00
OnCalendar=Mon..Fri 9..11,14..16,0..5:00:00

# Vacation
#OnCalendar=*-*-* *:00:00

# asynchrone execution (?)
Persistent=0

AccuracySec=1sec

[Install]
WantedBy=timers.target

myjob-sleep.service

[Unit]
Description=MyJob sleep hook
Before=sleep.target
StopWhenUnneeded=yes
RefuseManualStart=yes

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/systemctl stop myjob.timer
ExecStop=/usr/bin/systemctl start myjob.timer

[Install]
WantedBy=sleep.target

explanation
Beware: This is a special situation and a special workaround. If you have same issues (and no solution yet) this shall give you an idea, how to achieve exact runs anyway.
For detailed explanation of special settings please consult man pages systemd.unit, systemd.service, and systemd.timer.

  1. Let’s start with myjob.timer: Nothing special so far - I tried to achieve only running on designated times through Persistent= and AccuracySec= >without< success.

  2. Solution part 1: running after resume from suspend/hibernate/etc.: myjob-sleep.service
    This service basically does shut down myjob.timer when any kind of hibernation is requested. (sleep.target is requested from any suspend- or hibernation-targets and therefore requests myjob-sleep.service, too)
    Initiating the hibernation will call ExecStart, meaning shutting down myjob.timer. After resume StopWhenUnneeded= applies and executes ExecStop=.
    Effectively shutting down the >timer< while the computer is sleeping, and starting up the >timer< on resume.
    → not running after resume, unless the timer is started up again and a OnCalendar= rule applies.

  3. Solution part 2: running after starting up the computer (after shutdown or reboot): myjob.service
    Of corse, myjob.service is just the executive unit in first place. The run on startup will be prevented through ExecStartPre=.
    First I verify the system is up longer than two minutes, otherwise we won’t let start anything. (At this point it is basically enough, but…)
    What’s about the case the timer shall let it run at 9:00:00 o’clock, but the startup was at 8:58:38 - the time spawn is shorter as 120 seconds and ExecStartPre= would block the 9 o’clock execution.
    To prevent this situation the lock file (lckf) comes in place: Created on failure while booting the machine, it allows the 9 o’clock execution, because it tells us: “On boot execution failed already”.
    In any other situations the 120 seconds are always passed and the lock file is no longer relevant. (It’s just covering a litte situation, which could apply, to achieve more accuracy.)

You could add for the “timers to be active on boot” (Source: systemd.special )

[Install]
WantedBy=timers.target

Sorry, I don’t get what you mean - usually systemctl enable --now myjob.timer is enough to have a timer running from start. Therefore only the .timer unit file needs this [Install] block I thought.
Please explain more detail where you think I should add this install section. I don’t get your point.

Did you maybe overlook the install section in myjob.timer?