Re: /usr busy after aptitude operations?
On Sun, May 11, 2008 at 08:53:06PM -0400, Douglas A. Tutty wrote: and had it remounted rw, no problem. Right. It only locks when unlinked files are in use do to a running application during an upgrade. This is mostly a userland problem, I think, since most daemons are restarted by their installation scripts during upgrades. -- Oh, look: rocks! -- Doctor Who, Destiny of the Daleks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr busy after aptitude operations?
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr busy after aptitude operations?
On Sat, May 10, 2008 at 09:59:09AM +0200, Sven Joachim wrote:
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.
Turns out you're right on the money:
http://lists.debian.org/debian-devel/2001/11/threads.html#00212
http://www.debian.org/doc/manuals/securing-debian-howto/ch4.en.html
so I decided to go with this:
Dpkg::Pre-Invoke {
/bin/mount -o remount,rw /usr;
/bin/mount -o remount,rw /boot;
/bin/mount -o remount,exec /tmp;
};
Dpkg::Post-Invoke {
/bin/mount -o remount,ro /usr || echo 'Warning: /usr is busy: try
killing X';
/bin/mount -o remount,ro /boot;
/bin/mount -o remount,noexec /tmp;
};
At least now it attempts to remount ro, and gives a sensible error if it
can't without causing apt to stop processing.
--
Oh, look: rocks!
-- Doctor Who, Destiny of the Daleks
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr busy after aptitude operations?
On Sun, May 11, 2008 at 11:03:26AM -0700, Todd A. Jacobs wrote: 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. I just su - , and ran: # mount -o,ro,remount /usr then ran # mount and saw that /usr was mounted ro, then ran # mount -o,rw,remount /usr and had it remounted rw, no problem. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr busy after aptitude operations?
On Sun, May 11, 2008 at 08:53:06PM -0400, Douglas A. Tutty wrote: On Sun, May 11, 2008 at 11:03:26AM -0700, Todd A. Jacobs wrote: 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) [snip] seeing as the original question was about running apt (aptitude), why not set up an alias for apt or aptitude like so TMP=/var/tmp aptitude or find some other sutable location which has exec or rw access' I realise this doesn't help with remounting /usr or /... as rw Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- We're working with Chancellor Schröder on what's called 10-plus-10-over-10: $10 billion from the U.S.,$10 billion from other members of the G7 over a 10-year period, to help Russia securitize the dismantling -- the dismantled nuclear warheads. - George W. Bush 05/23/2002 Berlin, Germany signature.asc Description: Digital signature
Re: /usr busy after aptitude operations?
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 [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr busy after aptitude operations?
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr busy after aptitude operations?
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr busy after aptitude operations?
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr busy after aptitude operations?
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 [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr busy after aptitude operations?
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 [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr busy after aptitude operations?
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr busy after aptitude operations?
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 [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
