[kwlug-disc] systemd timer VS crontab

[Chris Irwin]

On Tue, Jan 06, 2026 at 10:59:26PM -0500, Gordon Dey wrote:
>Systemd...
>doesn't cope well with non-dhcp nfs networks. It's meant for a laptop 
>user in a cafe, perhaps? I munge /etc/network/interfaces, /etc/hosts, 
>/etc/resolv.conf and turn off the resolved and time sync to make 
>systems stable and predictable.

Do you have a link to any bug reports? I'm very curious how NFS breaks 
with static addresses, or how *disabling* time sync (presumany chrony?) 
is involved.

Both Fedora and RHEL are still using NetworkManager by default, so I 
don't really have much experience with systemd-networkd.

For resolv.conf, we've actually migrated our servers to use 
systemd-resolved (which isn't the default in RHEL) to resolve occasional 
issues with host lookups.

One of the quirky issues being DNS1 undergoing maintenance, but DNS2 is 
still online. Sometimes programs will fail a DNS lookup, or won't repeat 
the request to the second DNS server. This problem is elimited with 
resolved.

It's also the only viable system-level way you can decide to enforce 
DNSSEC, assuming your infrastructure is prepared for that. Unless you 
decide to implement another similar service like dnsmasq.

FWIW, it's killer DNS feature is for machines on multiple networks, or 
with split-routing VPNs. It's intelligent enough to identify which 
network's DNS servers to send requests to, preventing DNS leakage in 
multi-route situations.

>It also does funky things with sockets that has had me wondering 
>what's up with gpsd when it shouldn't touch gpsd.

Probably just socket activation? Socket activation predates systemd by a 
few decades (inetd, xinetd, etc). However, it's become significantly 
easier with systemd, hence why more services are switching to it lately.

That's generally a nice thing for some services to be fired up on 
demand, instead of always running. But sometimes you may not want that 
For example, gpsd probably takes time to get a lock, which may be a 
problem if you're using it as a time source, vs wanting to look at a 
map.

You can probably do something like the following to simply start the 
service normally, instead of via socket:

$ sudo systemctl disable gpsd.socket
$ sudo systemctl enable --now gpsd.unit

>The binary journalctl means that figuring out what went wrong in boot 
>is far more tedious than a simple grep over /var/log/*.log. I don't 
>need the fancy pagination and process tree. Just the log, thanks.

I've found journalctl to be generally nicer than plain log files.

We have multiple services that all log into journald (well, they just 
output to stdout, but systemd routes that to the journal automatically). 
If I'm troubleshooting an issue involving multiple services, I can do 
the following:

     journalctl -u service1.unit -u service2.unit

Then I get can read through log output of both services together, rather 
than two windows with separate logs, and jumping around to line things 
up.

One of my gripes is that apache httpd and samba still use their own log 
files.

-- 
Chris Irwin

email:   chris at chrisirwin.ca
  xmpp:   chris at chrisirwin.ca
   web: https://chrisirwin.ca