On 2020-02-26, Joe Beanfish wrote:

> 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)

Well, I see what you mean, but if it has variables in it that I need
to change to get the service to run at a different time or with
different options, then it looks, walks, & quacks ike a config file to
me!

;-)


--
Some say the world will end in fire; some say in segfaults.
                                    

--- SoupGate-Win32 v1.05