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 help, 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

On Sat, May 10, 2008 at 09:59:09AM +0200, Sven Joachim wrote:
> 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.

When you mount the filesystem, are all the standard options active or do
you mount it noatime? I don't know if it matters.

What happens if you do the remounting pre/post manually instead?
Especially if you do it as part of a shell script:

remount...
aptitude
(use it interactively)
remout...

If that works, then there's a bug.

I used to have /usr and /boot mounted ro routinely in Sarge with no
problem.

Doug.


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

On Sat, May 10, 2008 at 07:36:34PM -0400, Douglas A. Tutty wrote:

> When you mount the filesystem, are all the standard options active or
> do you mount it noatime? I don't know if it matters.

I'm mounting it with relatime. Mount says:

/usr type xfs (rw,relatime,barrier,logbufs=8)

I'm not sure why that should matter, though.

> What happens if you do the remounting pre/post manually instead?

$ sudo mount -o remount,ro /usr
mount: /usr is busy

Since I can't do it manually, I'm not surprised it can't be done by apt,
but some of the questions people are asking make me wonder if it's an
interaction between XFS and apt, or if it's a problem with ext3 as well.
I have no way to test it; maybe someone else can chime in on that.

> I used to have /usr and /boot mounted ro routinely in Sarge with no
> problem.

Me, too, which is why this is annoying me tremendously.

--
"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