Am Di., 11. Juni 2019 um 16:18 Uhr schrieb Reindl Harald <h.reindl@xxxxxxxxxxxxx>: > > > > Am 11.06.19 um 15:00 schrieb Ulrich Windl: > >>>> Reindl Harald <h.reindl@xxxxxxxxxxxxx> schrieb am 11.06.2019 um 14:30 in > > Nachricht <917331d8-845f-54d5-908c-e6c7d124a3c6@xxxxxxxxxxxxx>: > >> > >> 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 "rc{service} rotate" to send > >> SIGHUP to the daemon as "postrotate" action. After converting (actually being > >> converted ;-)) to systemd I dropped the LSB script, and wonder which command > >> to use as "postrotate" action: > >>> > >>> Should I implement a oneshot service (using "systemctl start {service}") > >> that does depend on the actual service and send a SIGHUP on start, or is > >> there a more elegent solution? > >> > >> that's what reload is all about > >> > >> [harry@srv-rhsoft:/etc/systemd/system]$ cat named.service | grep Reload > >> ExecReload=/usr/bin/kill -HUP $MAINPID > > > > The manual page says it's about "configuration reload". I was talking about logfile rotation (my service does not suport configuration reload (other than restart)) > > frankly it's nothing new or uncommon that services close and re-open > their logfiles by "reload" and that's really not systemd specific, > sysvinit had reload too > > it's you turn what happens with "systemctl reload yourservice" becaus > ethere is no default action for that unless "ExecReload" is specified Of course you can do whatever you please in ExecReload, but as said I think it's good practice if "reload" has a certain consistent meaning across services so admins not familiar with a particular service know what to expect from "systemctl reload". See also https://github.com/rsyslog/rsyslog/commit/fd26a42bdc04eaf497cafd9ef806a54f3de1a7e9#diff-c64e6ed7f40ecd1530e093a77c9465f6 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel