Am Di., 11. Juni 2019 um 16:18 Uhr schrieb Reindl Harald
:
>
>
>
> Am 11.06.19 um 15:00 schrieb Ulrich Windl:
> Reindl Harald schrieb am 11.06.2019 um 14:30 in
> > Nachricht <917331d8-845f-54d5-908c-e6c7d124a...@thelounge.net>:
> >>
> >> Am 11.06.19 um 13:34 schrieb Ulrich Windl:
> >>> I
Am 11.06.19 um 15:00 schrieb Ulrich Windl:
Reindl Harald schrieb am 11.06.2019 um 14:30 in
> Nachricht <917331d8-845f-54d5-908c-e6c7d124a...@thelounge.net>:
>>
>> Am 11.06.19 um 13:34 schrieb Ulrich Windl:
>>> I have a forking service (with a PID file) that can reopen the logfile
>>>
Am Di., 11. Juni 2019 um 15:00 Uhr schrieb Ulrich Windl
:
>
> >>> Reindl Harald schrieb am 11.06.2019 um 14:30 in
> Nachricht <917331d8-845f-54d5-908c-e6c7d124a...@thelounge.net>:
>
> >
> > Am 11.06.19 um 13:34 schrieb Ulrich Windl:
> >> I have a forking service (with a PID file) that can reopen
>>> Reindl Harald schrieb am 11.06.2019 um 14:30 in
Nachricht <917331d8-845f-54d5-908c-e6c7d124a...@thelounge.net>:
>
> Am 11.06.19 um 13:34 schrieb Ulrich Windl:
>> I have a forking service (with a PID file) that can reopen the logfile after
> receiving SIGHUP. In the past I had implemented
>>> Michael Biebl schrieb am 11.06.2019 um 14:13 in Nachricht
:
> A separate oneshot service sounds like overkill. I would probably use
> something like
> `systemctl kill -s HUP ${service}.service`
> If your sevices spawns multiple processes and you only want to send
> SIGHUP to the main process,
