I have the following in /etc/apt/apt.conf:

Dpkg::Pre-Invoke {"/bin/mount -o remount,rw /usr";};
Dpkg::Post-Invoke {"/bin/mount -o remount,ro /usr";};

However, in many cases, running aptitude results in the following error:

mount: /usr is busy
E: Problem executing scripts DPkg::Post-Invoke '/bin/mount -o remount,ro /usr'
E: Sub-process returned an error code

I can't figure out why aptitude is leaving the partition in a state
where it can't be remounted ro, even after a significant amount of time
has passed or /bin/sync has been called.

Running "fuser -vm /usr" reveals that /usr/lib/iceweasel/firefox-bin is
being left open for writing (why???), but even after closing firefox and
seeing /usr/lib/iceweasel/firefox-bin disappear from the fuser output,
the problem remains the same.

How do I work around this issue, or at the very least find out why the
filesystem is being held open?

--
"Oh, look: rocks!"
-- Doctor Who, "Destiny of the Daleks"


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hi Todd,

/usr holds almost all active binaries (/usr/bin) and libraries
(/usr/kib), you will not be able to umount it.
First step of "remount" is a umount.

cheers

Todd A. Jacobs wrote:
> I have the following in /etc/apt/apt.conf:
>
> Dpkg::Pre-Invoke {"/bin/mount -o remount,rw /usr";};
> Dpkg::Post-Invoke {"/bin/mount -o remount,ro /usr";};
>
> However, in many cases, running aptitude results in the following error:
>
> mount: /usr is busy
> E: Problem executing scripts DPkg::Post-Invoke '/bin/mount -o remount,ro /usr'
> E: Sub-process returned an error code
>
> I can't figure out why aptitude is leaving the partition in a state
> where it can't be remounted ro, even after a significant amount of time
> has passed or /bin/sync has been called.
>
> Running "fuser -vm /usr" reveals that /usr/lib/iceweasel/firefox-bin is
> being left open for writing (why???), but even after closing firefox and
> seeing /usr/lib/iceweasel/firefox-bin disappear from the fuser output,
> the problem remains the same.
>
> How do I work around this issue, or at the very least find out why the
> filesystem is being held open?
>
>


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On 2008-05-08 19:36 +0200, Todd A. Jacobs wrote:

> I have the following in /etc/apt/apt.conf:
>
> Dpkg::Pre-Invoke {"/bin/mount -o remount,rw /usr";};
> Dpkg::Post-Invoke {"/bin/mount -o remount,ro /usr";};
>
> However, in many cases, running aptitude results in the following error:
>
> mount: /usr is busy
> E: Problem executing scripts DPkg::Post-Invoke '/bin/mount -o remount,ro /usr'
> E: Sub-process returned an error code
>
> I can't figure out why aptitude is leaving the partition in a state
> where it can't be remounted ro, even after a significant amount of time
> has passed or /bin/sync has been called.

Probably the problem is that many files which have been upgraded are
still open (binaries and libraries). If the system were to remount /usr
read-only, their inodes could not be freed any more, resulting in file
system corruption.

> Running "fuser -vm /usr" reveals that /usr/lib/iceweasel/firefox-bin is
> being left open for writing (why???), but even after closing firefox and
> seeing /usr/lib/iceweasel/firefox-bin disappear from the fuser output,
> the problem remains the same.

Maybe lsof would be more informative, but that spits out rather many
files; fuser does not list libraries.

> How do I work around this issue, or at the very least find out why the
> filesystem is being held open?

Closing down X could be of great , but I guess that is not quite
what you want to hear. Maybe someone else has a better idea.

Sven


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On 2008-05-08 20:45 +0200, n0bert0 wrote:

> Hi Todd,
>
> /usr holds almost all active binaries (/usr/bin) and libraries
> (/usr/kib), you will not be able to umount it.
> First step of "remount" is a umount.

No, where did you get that idea? Please read mount(2).

Sven


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Todd A. Jacobs, 05/08/2008 07:36 PM:

> I have the following in /etc/apt/apt.conf:
>
> Dpkg::Pre-Invoke {"/bin/mount -o remount,rw /usr";};
> Dpkg::Post-Invoke {"/bin/mount -o remount,ro /usr";};

Why?


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, May 08, 2008 at 10:26:54PM +0200, Peter Jordan wrote:

> > Dpkg::Pre-Invoke {"/bin/mount -o remount,rw /usr";};
> > Dpkg::Post-Invoke {"/bin/mount -o remount,ro /usr";};

> Why?

Because /usr has no business being mounted rw most of the time. You only
need to write to /usr during a package upgrade.

Even with a journaling filesystem, there are plenty of ways that a
sudden shutdown can hose your system. In addition, you get an admittedly
small boost in security by not having the filesystem writable without
root taking explicit steps.

Actually, it doesn't really matter why. It should work, and it doesn't.
That's the point.

--
"Oh, look: rocks!"
-- Doctor Who, "Destiny of the Daleks"


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, May 08, 2008 at 08:50:53PM +0200, Sven Joachim wrote:

> Probably the problem is that many files which have been upgraded are
> still open (binaries and libraries). If the system were to remount

I know that dpkg takes steps to unlink files without actually deleting
them during an upgrade, so your suggestion makes some sense, but I'm not
quite sure why the system would need to keep inodes open for writing
after that. It still seems somewhat bug-like to me.

Shutting down X, or switching to runlevel 1, really doesn't make the
process transparent. I really might as well reboot if that's the case,
but that also defeats a great deal of the purpose of being able to
upgrade a live system.

--
"Oh, look: rocks!"
-- Doctor Who, "Destiny of the Daleks"


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On 2008-05-10 09:18 +0200, Todd A. Jacobs wrote:

> I know that dpkg takes steps to unlink files without actually deleting
> them during an upgrade, so your suggestion makes some sense, but I'm not
> quite sure why the system would need to keep inodes open for writing
> after that. It still seems somewhat bug-like to me.

The filesystem has to be written to after the inodes are freed, i.e. the
offending process that kept them open has exited. You would end up with
inodes that have a link count of 0, i.e. lost space on the device, if
the system would not do that.

> Shutting down X, or switching to runlevel 1, really doesn't make the
> process transparent. I really might as well reboot if that's the case,
> but that also defeats a great deal of the purpose of being able to
> upgrade a live system.

True, but I don't have a better suggestion; maybe someone else has.

Sven


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org