Re: Antw: Re: Binary changed since start

[Michael Biebl <mbiebl@xxxxxxxxx>]

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.Windl@xxxxxxxxxxxxxxxxxxxx>:
>
> >>> 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
> ...
>
> > 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



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