There is a tool called needrestart which should do exactly what you want. See https://tracker.debian.org/pkg/needrestart https://github.com/liske/needrestart
Am Di., 10. Dez. 2019 um 15:12 Uhr schrieb Ulrich Windl <ulrich.wi...@rz.uni-regensburg.de>: > > >>> Lennart Poettering <lenn...@poettering.net> schrieb am 10.12.2019 um 12:32 > in > Nachricht <20191210113234.GA16721@gardel-login>: > > On Di, 10.12.19 10:38, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de) > wrote: > > > >> Hi! > >> > >> Two questions (In Linux it's possible to replace the image of the binary > > that is executed on disk): > >> > >> 1) It seems my version of systemd (228) does not detect that a > >> binary has changed since the service was started. In case it's still > >> true in the current version, is it difficult to indicate that fact > >> in "systemctl status .."? > > > > We don't, no. It has been requested before that we deal with that, but > > it's not realistic to do this correctly. Thing is, binaries are > > Well at least "zypper ps" does that kind of things: > # zypper ps > The following running processes use deleted files: > > PID | PPID | UID | User | Command | Service | Files > ------+-------+------+------------+----------------+----------------+-------------------------------------- > 2502 | 1 | 0 | root | multipathd | multipathd | > /lib64/libtinfo.so.5.9 > 2903 | 1 | 100 | messagebus | dbus-daemon | dbus | > /lib64/libnss_sss.so.2 > 2967 | 1 | 0 | root | mcelog | mcelog | > /lib64/libnss_sss.so.2 > 3774 | 1 | 0 | root | xinetd | xinetd | > /lib64/libnss_sss.so.2 > 3796 | 1 | 1086 | nagios | nrpe | nrpe | > /lib64/libnss_sss.so.2 > 3973 | 1 | 0 | root | sshd | sshd | > /lib64/libnss_sss.so.2 > 4060 | 1 | 0 | root | automount | autofs | > /usr/lib64/libxml2.so.2.9.4 > 4074 | 1 | 0 | root | snmpd | snmpd | > /lib64/libnss_sss.so.2 > 4079 | 1 | 74 | ntp | ntpd | ntpd | > /lib64/libnss_sss.so.2 > 4080 | 4079 | 74 | ntp | ntpd | ntpd | > /lib64/libnss_sss.so.2 > 4082 | 1 | 25 | at | atd | atd | > /lib64/libnss_sss.so.2 > 4166 | 1 | 0 | root | bash | md-mon | > /lib64/libtinfo.so.5.9 > ... > 25512 | 1 | 0 | root | cupsd | cups | > /lib64/libnss_sss.so.2 > 26053 | 3973 | 0 | root | sshd | | > /lib64/libnss_sss.so.2 > 26061 | 26053 | 0 | root | bash | | > /lib64/libnss_sss.so.2 > > # zypper ps -s > The following running processes use deleted files: > > PID | PPID | UID | User | Command | Service > ------+-------+------+------------+----------------+--------------- > 2502 | 1 | 0 | root | multipathd | multipathd > 2903 | 1 | 100 | messagebus | dbus-daemon | dbus > 2967 | 1 | 0 | root | mcelog | mcelog > 3774 | 1 | 0 | root | xinetd | xinetd > 3796 | 1 | 1086 | nagios | nrpe | nrpe > 3973 | 1 | 0 | root | sshd | sshd > 4060 | 1 | 0 | root | automount | autofs > 4074 | 1 | 0 | root | snmpd | snmpd > ... > > > generally not statically compiled, they link against other libraries > > which might also be updated, and which would have to be checked > > too. And they do so via module loading (i.e. dlopen()) and explicitly, > > we'd have to check both, which already is harder, since you cannot > > just look at the ELF headers of binaries to determine deps > > anymore. But they also keep other resources mapped, for example l10n > > and i18n data, and a lot of other stuff. We'd have to check that > > too. And then, there are the invisible dependencies too: some file > > changed that some library a program opens and reads, but only > > sometimes: how would you ever figure out you need to restart the > > service? And then, there's also the fact that C is just one > > programming language and others work very differently, and require > > other schemes for updating, i.e. Python does something very very > > different. > > > > So in the end: implementing something like that could at best be a > > heuristic, that works sometimes but not generally. I know that some > > distros implemented a checker for this in their package manager. But I > > am very sure this has no place in systemd, since it's black magic and > > you never could rely on the correctness for that. > > > >> 2) Given 1), would it make sense to allow an option like > >> "RestartIfBinary Changed"? > > > > Binding control flow to such a heuristic sounds even more dangerous to > > me. > > I was asking for an option, not for a default. > > Regards, > Ulrich > > > > > > Lennart > > > > ‑‑ > > Lennart Poettering, Berlin > > > > _______________________________________________ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
