Add After=network-online.target to the [Unit] section of the timer.
Timers do accept all the relative ordering commands in the [Unit] section that are known for services. In fact both the [Unit] and [Install] sections are identical for timers and services. Form the official manuals:
A unit configuration file whose name ends in ".timer"...
This sort of problem is supposed to be fixed by the package maintainer. In anacron’s case, the bug is filed as #993348: the previous version of anacron shipped its systemd files in /lib/systemd, the new version moved them to /usr/lib/systemd but didn’t update any symlinks in /etc.
However /etc is owned by the system administrator, not the package manager, so ...
systemd is developed primarily by RedHat employees, Fedora is their main testbed distribution for RHEL, so you can imagine that Fedora enables most of systemd features.
If you want to be on the bleeding edge you could use Fedora Rawhide which normally contains the latest version and all the newest features of systemd.
My suspicion is that ps is trying to turn the numeric UID into a username, doing a lookup for that UID, then timing out. After the failed lookup, the numeric ID is displayed.
See if these two commands show a difference:
ps -o uid -p 31891
ps -o uname -p 31891
Now why would it be doing that lookup and timing out? Could you have NIS configured for usernames?...
Run systemctl --user without any other parameters to see a listing of all units the user-level services can interact with. You will probably find something like sys-subsystem-net-devices-eno1.device.
But note that this might not be the optimal way to react on network status changes: instead, you could drop a script into /etc/NetworkManager/dispatcher.d/ or ...
Let's say your timer is /etc/systemd/system/foo.timer, then you can create a file /etc/systemd/system/foo.timer.d/override.conf with the contents
which will override the OnCalendar specification from /etc/systemd/system/foo.timer. It might be necessary to run systemctl daemon-reload after changing override.conf.
That timestamp probably comes from the build-time of the systemd daemon, and not the build time of the kernel (uname). I don't know where /etc/timestamp comes from.
After looking at systemd code, I think the build-time is set when the systemd binaries are compiled, or if present, from the file /usr/lib/clock-epoch
This is the error message:
$ ag 'System time ...
Ok, after further investigating this and got a shot on the flickering text on the screen I figured out which was the issue: The live system automatically generates the live-user "user" which was not existent in my build. So with the post, here: https://serverfault.com/a/1030050 I managed to disable the creation of this user and now everything is ...
From the error message, it looks like the Working Directory line used to be WorkingDirectory=~/TimberApi but has been edited to its current form WorkingDirectory=/home/ubuntu/TimberApi without running systemctl daemon-reload afterwards, so systemd is still using the old version.
So just running systemctl daemon-reload should fix it.
If you use the systemctl ...
I found one possible cause: The service run by the timer had developed a bug which turned into an infinite loop. Since systemd timer's normally don't standard a second instance of a service if there's one already running, the timer appeared to have stopped scheduling new events.
One clue I got was comparing a stuck timer and a freshly started one. I used ...
When you use systemctl list-timers you are listing the active *.timer units.
stew ~ $ systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Wed 2021-09-08 10:32:20 CEST 46min left Wed 2021-09-08 09:32:47 CEST 13min ago anacron.timer ...
The proper solution looks like this:
You cannot mix hour and minutes in the notation, which is why this form does not work:
The hourly range needs to be defined before specifying minutes. In this case the hourly range is:
The package is broken for some reasons, you should have anacron.timer under /usr/lib/systemd/system/, here is the list of files provided by anacron.
The symlinked anacron.timer can be:
ls -al /etc/systemd/system/timers.target.wants/anacron.timer
/etc/systemd/system/timers.target.wants/anacron.timer -> /lib/systemd/system/anacron.timer
Bug in Xubuntu 20.04 with same symptoms due to a screensaver mismatch. You might check your settings for that on Ubuntu as well.The process it's waiting for might just be for the screensaver to exit (even if it's not actually doing anything.) Unfortunately on Xubuntu if you disable the screensaver, the problem still occurs!
I've replaced the X-screensaver ...
You should be able to tell rsyslogd to reopen the log-files with something like:
/usr/bin/systemctl kill -s HUP rsyslog.service
I have not yet found how to make it reload its configuration, most hits says you need to restart it to apply new configuration.
I found this serverfault question that links information it is not possible:
If all the above options are already set, try adding systemd.unified_cgroup_hierarchy=1 to your kernel command line.
This enables cgroups v2, which was the missing piece (at least for my setup) to enable IP firewalling in BPF and get rid of the error in dmesg logs.