W dniu 10.12.2019 o 15:12, Ulrich Windl pisze: >>>> Lennart Poettering <lennart@xxxxxxxxxxxxxx> schrieb am 10.12.2019 um 12:32 > in > Nachricht <20191210113234.GA16721@gardel-login>: >> On Di, 10.12.19 10:38, Ulrich Windl (Ulrich.Windl@xxxxxx‑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 > ... > Well. This specifically may be doable by checking if any file open by process is marked deleted, but would not work if the file was just rewritten... >> 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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/systemd-devel >
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel