[systemd-devel] Antw: Re: Binary changed since start

[Michał Zegan]

W dniu 10.12.2019 o 15:12, Ulrich Windl pisze:
>>>> Lennart Poettering <lennart at poettering.net> schrieb am 10.12.2019 um 12:32
> in
> Nachricht <20191210113234.GA16721 at gardel-login>:
>> On Di, 10.12.19 10:38, Ulrich Windl (Ulrich.Windl at 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
> ...
> 
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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20191210/3aa4b9b9/attachment.sig>