On Tue, 25 Feb 2020 15:56:58 +0000, Adam Funk wrote:

> On 2020-02-25, Joe Beanfish wrote:
>
>> On Tue, 25 Feb 2020 09:40:16 +0000, Adam Funk wrote:
>>
>>> On 2020-02-24, Richard Kettlewell wrote:
>>>
>>>> Adam Funk  writes:
>>>>> On 2020-02-24, Richard Kettlewell wrote:
>>>>>> Adam Funk  writes:
>>>>>>> On 2020-02-20, Richard Kettlewell wrote:
>>>>>>>> You stopped reading too early:
>>>>>>> ...
>>>>>>>> Start with ‘man systemd.timer’ for the syntax & meaning of the
>>>>>>>> timer file, and look for ‘Overriding vendor settings’ in ‘man
>>>>>>>> systemd.unit’
>>>>>>>> for how to modify its behavior.
>>>>>>>
>>>>>>> Thanks --- I think I'm getting closer, but not successful yet.  I
>>>>>>> found a symlink from
>>>>>>> /etc/systemd/system/timers.target.wants/anacron.timer to
>>>>>>> /lib/systemd/system/anacron.timer, deleted it, copied the linked
>>>>>>> file
>>>>>>                                      ^^^^^^^^^^
>>>>>>
>>>>>> I have no idea why you would do that.
>>>>>
>>>>> Some stuff in the documentation led to believe that customized files
>>>>> should go straight in etc --- should I restore the symlink and edit
>>>>> the file in /lib/systemd/...?
>>>>
>>>> The symlinks needs to still be there but point to the new file.
>>>
>>> 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.
>>
>> 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.
>
> 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?

The .service files aren't config files. It's just that some packagers
plunk hard-coded settings into the .service file when they should
make them configurable. e.g. redhat/centos hardcode "PrivateTmp=true"
into the .service file for apache httpd.

So instead of

[Service]
ExecStart=/usr/sbin/mydaemon -s 03:00:00
PrivateTmp=true

It should be

[Service]
EnvironmentFile=/etc/sysconfig/mydaemon
ExecStart=/usr/sbin/mydaemon -s $STARTTIME
PrivateTmp=$USEPRIVATETMP

Then all tweakable settings go in /etc/sysconfig/mydaemon instead
of the .service file. (or /etc/default or whatever)

--- SoupGate-Win32 v1.05