Home_greyopenFATE - openSUSE feature tracking > #300763
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

Warn about services using old libraries

Feature state

openSUSE-10.2
Rejected Information
openSUSE-10.3
Rejected Information
openSUSE-11.0
Rejected Information
openSUSE-11.1
Rejected Information
openSUSE-11.2
Done

Description

Fou4s has a useful feature: after installing updates, it runs "lsof | grep RPMDELETE" to see processes that are accessing the old libraries and recommends to restart them.

Our update stack should do this as well, and notify users of processes that need to be restarted.

I see this as both a zypper feature and a PK-UI pop-up.

Documentation impact

Software management documentaiton needs to be updated.

Discussion


icons/user_comment.png S. V. wrote: (11 years ago)

Edith, Jiri, feel free to postpone this for 10.3 if out of resources.

icons/user_comment.png E. P. wrote: (10 years ago)

Sorry, we had no time to look into this. Please reject for 10.3.

icons/user_comment.png F. L. wrote: (10 years ago)

I like this. Stano, Klaus, please sanity-check.

icons/user_comment.png J. S. wrote: (9 years ago)

Jiri, please, add the check into YaST online update (I must admit that the suggested command didn't work for me, thus some investigation may be needed).

Duncan, please, assign the applets.

icons/user_comment.png J. S. wrote: (9 years ago)

Uhm, what should be the output of "lsof | grep RPMDELETE" and what should actually YaST do with the result?

Or, if we use the command from comment 4: what should YaST do with these results?

icons/user_comment.png M. V. wrote: (9 years ago)

When packages are updated, the effect of the update may not be yet realized because the system is still using the old files (they are unlinked but still in use). A well known case is the kernel which needs a reboot (or kexec or ksplice...). For the apps, we can ask (in zypp app layer?) about all open files which are already unlinked. Then we can say "Updates will not take effect until these processes are restarted: sshd (pid 42), apache2 (pid 31337). If you are unsure, rebooting will do the job.". There can be a Details button or a reference to "zypper checkdeleted" (TODO) to show the gory details.

It seems that RPMDELETE no longer works, but there is a
simple fix for that.

This thread shows how fou4s presents the info. Marcus has good points in comment 4 but we can address them when we have a prototype working.

icons/user_comment.png J. S. wrote: (9 years ago)

IMHO such check belongs to zypp, YaST/zypper/applets should show the results. Duncan, is it possible to assign this to someone from the zypp team?

icons/user_comment.png D. M. wrote: (9 years ago)

yes, will be done as part of the commit refactoring.

icons/user_comment.png D. M. wrote: (8 years ago)

This will be implemented as a chain in the commit refactoring, by calling a external binary that will look in /proc for binaries with deleted libraries opened.

The RPMDELETE stuff does not work in reality like it is described.

Also may be good to create a good set of callbacks so libzypp can present a summary of services to restart and also config files that were modified.

icons/user_comment.png M. A. wrote: (8 years ago)

libzypp-6.13.1 provides class CheckAccessDeleted and an example command zypp-CheckAccessDeleted to check for running processes which access meanwhile deleted files or libraries. This class may be used after commit, trying to figure out which services need to be restated. tools/zypp-CheckAccessDeleted.cc shows how to use the class, it's pretty easy.

$ zypp-CheckAccessDeleted 
PID PPID UID LOGIN COMMAND SERVICE FILES
1900 1 216 ma wish - /lib/libexpat.so.1
3844 1 0 root fetchmail fetchmail /var/run/nscd/dbOioVty
...

It's currently not integrated into the commit workflow, because it is a standalone usable fetaure. For the application it's probably far easier to use CheckAccessDeleted directly, than trying to communicate via a callback. At least unless we want to strip down the functionality to siply return a list of service names from commit, without further context. For this I can offer an option to commit, that simply returns a list of service names.

icons/user_comment.png J. K. wrote: (8 years ago)

OK, i'll do this check in zypper after each commit and advise users to restart the services.

icons/user_comment.png J. K. wrote: (8 years ago)

Hm... after an upgrade of zlib one gets quite a number of hits :O) The filelist can also be huge (is this the list of all files used by the process?). I guess showing an abbreviated (or at least terse) list of processes would be appropriate, with a hint how to view the complete list with all of the affected files. What about a separate command, or write the complete list to a file in ~/.zypp and tell the user to view this file?

icons/user_comment.png M. A. wrote: (8 years ago)

  • I'm going to fix the filelist containing duplicate entries.
  • The default search looks for deleted open or memory mapped files. I can add an option to focus on detecting libs only. This will reduce the number of processes found.
  • We should keep in mind that this search might be a long running operation, and as it has to stat a lot of files, it may even block. IMO we should not call it automatically after each commit. And we should not store this volatile information in some file.
Maybe we should just ask/encourage the user to call (/usr/bin/)zypp-CheckAccessDeleted, or offer this check as a separate command in zypper (zypper CheckAccessDeleted).

icons/user_comment.png M. A. wrote: (8 years ago)

libzypp-6.13.2 provides no more duplicates and tries harder to report libs and executables only.

icons/user_comment.png J. K. wrote: (8 years ago)

Works nicely now. I also changed zypper to show the list only if there were packages to upgrade/downgrade or remove in the summary. It's in git; will be in zypper 1.2.4.

The only thing that might be improved is that the processes are shown after each commit from the moment the file has been deleted until the process gets restarted or destroyed. So, if you e.g. do a zlib upgrade, you'll get a big table each time you do zypper up or zypper rm until you restart the machine (or all the processes). This could be annoying... do we want to try to improve it?

icons/user_comment.png D. M. wrote: (8 years ago)

This requires to use 11.2 libzypp on SP1. Backport is basically adding all the 11.2 refactorings to the 11.1/SLE11 code.

icons/user_comment.png M. A. wrote: (8 years ago)

No, you can backport just the new class CheckAccessDeleted. It requires just 'lsof' being installed.

icons/user_comment.png J. K. wrote: (8 years ago)

'zypper ps' added to show the list. The check will still be done after each upgrade/removal/downgrade, but only notification will be shown, suggeting to use 'zypper ps' to see the list.
Marking 'done' for 11.2.

icons/user_comment.png S. B. wrote: (8 years ago)

Any update on this?

Keep in mind that feature freeze is this Friday.

icons/user_comment.png J. K. wrote: (8 years ago)

We're putting 11.2 packages to SP1, so this feature comes there for free. Closing as done.

Last change: 8 years ago
Voting
Score: 9
  • Negative: 0
  • Neutral: 0
  • Positive: 9
Tags
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint