LinuxQuestions.org - How does yum (or rpm or other pm) update/upgrade in use packages

- Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)

- - How does yum (or rpm or other pm) update/upgrade in use packages (https://www.linuxquestions.org/questions/linux-software-2/how-does-yum-or-rpm-or-other-pm-update-upgrade-in-use-packages-587002/)

How does yum (or rpm or other pm) update/upgrade in use packages

Hi,

I have tried looking around on Google and LQ for an answer to this question, but I can't seem to find the answer, and I'm hoping that someone here knows the answer. For reference I am running FC6 so if there is any distro specific stuff below, that is what I am using for a reference.

When I issue a "yum upgrade openssh" while connected to the machine via ssh, the sshd process is obviously running, but I don't get disconnected during the upgrade and yet it still seems to work. As I understand it, when rpm replaces an in use file, it renames the old file to a new name and/or location and then replaces the file and sends a HUP signal to the process.

However, if this is what happens, then I still have a few lingering questions about this process. When a process like sshd gets restarted with a HUP signal, it apparently doesn't completely shutdown because my ssh session doesn't close, and apparently the new process doesn't totally take over because I see the following entry in my /var/log/security after a "yum update openssh":

Code:

Sep 24 09:30:21 [hostname removed] sshd[477]: Received signal 15; terminating.

Sep 24 09:30:22 [hostname removed] sshd[659]: Server listening on :: port 22.

Sep 24 09:30:22 [hostname removed] sshd[659]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.

From this it appears that the old sshd is still running and bound to port 22. So my two questions are:

(1) As I understand it the old sshd executable still exists somewhere and is running. What is the convention that rpm uses to rename/move in use files that are replaced, and what eventually happens to them? (i.e. how do I make sure that they get deleted/removed at some point in the future. Is this taken care of by one of the daily/weekly/monthly cron jobs)

(2) From the logs it appears that the new sshd process fails to start up properly (or at least fails to bind to port 22, and so isn't listening for new connections anywhere). Do I need to do anything to finish the transition? I have tried a "service sshd restart", but I get exactly the same log message. Do I have to reboot the machine to finish this update, or will it eventually resolve itself if I log out for a while?

Thanks,
engineman

Hi.

On Linux, it's possible to remove in-use files (like your sshd executable) and replace them, but still have them available to running processes:

Quote:

When you open a file, the kernel follows the link, and assigns the inode a file descriptor (a number that it keeps track of internally). When you delete the file, you are "unlinking" the inode; the file descriptor still points to it. You can create a new file with the exact same name as the old file after deleting it, effectively "replacing" it, but it will point to a different inode. Any programs that still have the old file open can still access the old file via the file descriptor, but you have effectively upgraded the program in place. As soon as the program terminates (or closes the file), and starts up (or tries to access it again), it accesses the new file, and there you have it, a completely in-place replacement of a file!

(from http://blogs.ittoolbox.com/linux/loc...ebooting-12826 )

In the case of SSH, there's an sshd process for each login, which isn't killed when you update the ssh package (although the master sshd process is, during the cleanup process in yum). While you remain logged in, you're still using the old version. As soon as you log out, though, the sshd process you were using dies and if you log back in, you'll be using the new version.

Exactly why you got a bind error, I'm not sure. Maybe the sshd process took too long to die before being restarted or something.

Dave