| 1 |
On Thu, Jan 12, 2017 at 1:06 AM, Michael Morak <michael.morak@×××××.com> wrote: |
| 2 |
> Hi, |
| 3 |
> |
| 4 |
> I have a similar setup. The problem is that some of your services may still |
| 5 |
> have open handles on files that no longer exist after updating (i.e. the |
| 6 |
> service, when originally started, opened an .so library file that it needs |
| 7 |
> to run, but the file then gets deleted or replaced during the emerge -u). |
| 8 |
> Simply restart all services (and other running programs) that have locks on |
| 9 |
> files that were updated. |
| 10 |
> |
| 11 |
> The reason those files do not show up in your lsof command is that they may |
| 12 |
> not be open for writing but only for reading. A read lock on a file may |
| 13 |
> still give you the "/ is busy" message, since the open-for-read file cannot |
| 14 |
> be (fully) deleted while a running application still has a lock on it. You |
| 15 |
|
| 16 |
I figured it would be something like that. But I don't understand the |
| 17 |
gory innards: |
| 18 |
|
| 19 |
process foobard requires a library foo.so. foobard was started when / |
| 20 |
was ro. Then / is mounted rw and a new version of foo.so is installed. |
| 21 |
Of course, foobard still uses foo.so (old). What prevents / to be |
| 22 |
remounted ro? foo.so (new) is already on disk, foo.so (old) is still |
| 23 |
being used, kept in RAM (I assume...) |
| 24 |
|
| 25 |
This is not a big problem to me, but I would like to have a better |
| 26 |
understanding. |
| 27 |
|
| 28 |
Thanks |
| 29 |
|
| 30 |
Jorge |
Archives