It would be really helpful for long-running servers if rc-status could report an additional state: service running but binary replaced. The intention would be to provide a simple notification where a given running executable differs from the binary stored on-disk, as happens when the package for a running service is upgraded. In this case, /proc/<pid>/exe for the process in question becomes a bad symlink, pointing to '<original executable> (deleted)' (noting that this differs from kernel processes which don't have an associated binary, which appear as target-less symlinks). Under normal circumstances, the 'exe' node beneath /proc/<pid> is a valid symlink to the filesystem location of the running binary. Reproducible: Always
Hi, I think a tool to detect replaced binaries would be a great idea. However, I think it is more appropriate for something like this to be part of util-linux so that anyone can find replaced binaries regardless of which init system they are using. Thanks, William
For reference, there's already a separate app-admin/checkrestart-0.47-r3 but upstream (https://web.archive.org/web/20120108102529/http://arcdraco.net/checkrestart) is long dead and even the domain is no longer registered. I've also written my own version (named before I found the above package) with minimal requirements, available from https://github.com/srcshelton/checkrestart. This script performs additional checks to try to avoid restarting services which might not be safe to restart if the user requests automatic restarts, and uses OpenRC utilities to avoid restarting services which aren't actually running (for example, pppd starts dhcpcd, but restarting dhcpcd in this case can cause network outages. Yes, I did do this during testing ;) All of these value-add features would be difficult to implement in a generic fashion which is init-agnostic. My feeling is that such a feature is actually very specific to each individual init implementation - but if this was felt to be useful then OpenRC could gain a small amount of additional process-tracking in order to integrate this functionality and take out some of the guesswork of mapping processes back to init scripts.
