Controlling the time of anacron's cron.daily in raspbian buster?

So restore the symlinnk from /etc/systemd/system/timers.target.wants/anacron.timer to /lib/systemd/system/anacron.timer & edit the latter (regular) file?

(It just seems weird to me to edit something in /lib rather than in /etc!)

Thanks.

No, the link needs to point to the new file.

Yes, it would be.

The "files" in etc are just symlinks to the files in lib. Systemd creates/deletes the links when you do systemctl enable/disable. Similar to how traditional init used init.d and rc* directories. You can edit in either place to the same effect, as long as you don't break the link.

One thing about editing those files tho. Chances are your changes will get overwritten if/when you update the system package containing them. So document what you did so you can do it again.

Dang it, I was hoping for something wonderful for keeping customization. What I found was

Q: I want to change a service file, but rpm keeps overwriting it in /usr/lib/systemd/system all the time, how should I handle this?

A: The recommended way is to copy the service file from /usr/lib/systemd/system to /etc/systemd/system and edit it there. The latter directory takes precedence over the former, and rpm will never overwrite it. If you want to use the distributed service file again you can simply delete (or rename) the service file in /etc/systemd/system again.

Which sounds like the road the OP went down initially. I always want to use the service file that comes with the latest software so everything's compatible & works as designed. I just want to tweak one setting in there, PrivateTmp to be specific.

Right now I have a little script that runs right after updates and checks the setting and edits the service file with sed as needed then runs systemctl daemon-reload;systemctl restart THE_SERVICE

I guess I'm stuck with that... Unless someone knows of deeper magic they're willing to share?

So where do I put the new/customized version of the regular file?

I'm used to the upgrade process (on Debian-based systems) warning me that a config file has changed upstream & giving me the options: keep my own file (with a copy of the new upstream file beside it, so I can deal with it later); install the new file (and rename my own file, so I can deal with it later); or show the diff & repeat the options.

Are you telling me systemd is going to break that?

its broken everything else...

From the instructions I pointed you at:

There are two methods of overriding vendor settings in unit files: copying the unit file from /lib/systemd/system to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ /etc/systemd/system and modifying the chosen settings. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Alternatively, one can create a directory named unit.d/ within

Yes, but not, AFAIK usable with Raspbian. The Fedora distro's dnf package manager is capable of updating config files without overwriting any customisations you may have previously applied, and this applies to systemd gubbins as well. If for some reason it has to clobber a custom setting, it flops the new file in after making a copy of the one it replaces.

Its dead easy to find these cases - just run "locate *.rpmnew" after running "dnf update". and then using diff and your favourite editor to reconcile the two. Can't think why Debian doesn't do something similar.

Er, that's just what Debian does: gives you a choice of which file to have active, old or new, and leaves the other one available for inspection. (*.dpkg-old, *.dpkg-dist in this case.)

If you want to combine a custom setting with always using the latest supplied config for the rest of the file, you need something a little more sophisticated than that. Manual editing, or something automated like Puppet or Ansible.

I've posted before I saw your correction - and I've never seen Debian do that - possib;le because my RPi is in pretty much standard state - just Postfix added and the sudo config tweaked to match my the way its set up on my other Fedora boxen.

It's clearly obvious to you how this works, so I appreciate your patience.

1. copy /etc/systemd/system/anacron.timer to /etc/systemd/system
2. edit /etc/systemd/system/anacron.timer to "05..23:30"
3. delete the symlink from /etc/systemd/system/timers.target.wants/anacron.timer to /lib/systemd/system/anacron.timer
4. replace that symlink with one to /etc/systemd/system/anacron.timer

Does that sound right? It seems very strange to me to have to copy a file into a higher bit of /etc/systemd/ then symlink it from further down the tree.

To be fair, this is the first problem I've had with it. In principle, I like the idea of proper config files rather than enormous shells scripts; but I'd prefer it if this followed the easier way fail2ban & some other things work, where you copy /etc/foo.conf to /etc/foo.local or foo.conf.local & delete everything except what you want to change.

Well, it it what I thought I was doing!

Yay, that worked! First cron.daily job started at 05:39 this morning.

Thanks to everyone for the advice.

It would be strange, but that?s not what it says.

^^^^^^^^^^^^^^^^^^^^^^^^^^^*******************

I will not be quoting these instructions again.

Well, as I said a few minutes ago, I managed to get it working by doing that. You said "the link needs to point to the new file" --- how else can I interpret that besides items 3 & 4 above?

"1. copy /etc/systemd/system/anacron.timer to /etc/systemd/system"

A copy that leaves the file where it was.

A copy that generates a new override file...

I guess I'm used to/talking about CentOS 7 which just stomps the .service file. It's not strictly a config file so I kinda get that they don't tag it as such. But it contains a setting that I think should be configurable. Anyhow, I'm wandering OT for the pi.