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

[Ulrich Windl]

>>> 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
...

> 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