Hi, I prefer a hands-on approach to system configuration, which involves making extensive modifications to configuration files and creating custom systemd units.
I noticed that arch-update.timer gets overwritten during updates, resetting its custom configuration to defaults. I want to minimize the risk of breaking the system and having to perform a TTY recovery. Is setting chattr +i on this file a safe workaround?
What means this?
What configurations were overwritten?
Oh, I changed the values to what works best for me. I wanted the check to run once a week, every Monday. I only left these two lines:
OnCalendar=Mon *-*-* 19:30:00
Persistent=true
I commented out everything else. The timer worked as expected, and it ran yesterday. But today I noticed the annoying notification appeared again. I checked the config and saw that it had been overwritten. So I’m thinking about setting chattr +i on the file.
But I mean .. what did you use to make those changes?
Somewhere like /usr/..?
If so then I would probably encourage the use of proper overwrites like in /etc/.
If related to systemd units then often using the edit option with systemctl would also work.
And I would still be surprised at a full overwrite because normally pacman would not do that - it would create a pacnew file.
I edited it with vim in /usr/lib/systemd/user/arch-update.timer. Unfortunately, there was no pacnew file.
And yes, everything worked correctly until the scheduled update ran. After that, the config was overwritten and reverted to the default values.
That’s why I’m curious about using chattr +i.
Chattr will do what it always does.
But you should not be editing files in /usr/lib.
Theres even an explicit section about this in the tools docs, which says much what I already did;
https://github.com/Antiz96/arch-update#modify-the-check-cycle
Not sure why that timer file is getting overwritten, but the issue I’d see doing +i is (at least from the docs) root can override it and since you run pacman as root…
Either way as mentioned, you always want to be editing stuff at the user level first (ie. ~./config) as generally programs look there first before going to the system stuff.