From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 47CEC1384B4 for ; Tue, 15 Jan 2013 14:48:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7CE4A21C0DB; Tue, 15 Jan 2013 14:47:49 +0000 (UTC) Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E253021C028 for ; Tue, 15 Jan 2013 14:47:47 +0000 (UTC) Received: from mail-da0-f50.google.com ([209.85.210.50]:53968) by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1Tv7np-000O6v-6f for gentoo-user@lists.gentoo.org; Tue, 15 Jan 2013 21:47:49 +0700 Received: by mail-da0-f50.google.com with SMTP id h15so64664dan.23 for ; Tue, 15 Jan 2013 06:47:46 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.66.87.67 with SMTP id v3mr107255169paz.63.1358261266363; Tue, 15 Jan 2013 06:47:46 -0800 (PST) Received: by 10.68.248.66 with HTTP; Tue, 15 Jan 2013 06:47:46 -0800 (PST) Received: by 10.68.248.66 with HTTP; Tue, 15 Jan 2013 06:47:46 -0800 (PST) In-Reply-To: <20130115145826.00706056@khamul.example.com> References: <20130115115721.16ea5ca0@khamul.example.com> <20130115110956.5c7e5a17@digimed.co.uk> <20130115145826.00706056@khamul.example.com> Date: Tue, 15 Jan 2013 21:47:46 +0700 Message-ID: Subject: Re: [gentoo-user] /home doesn't umount on shutdown From: Pandu Poluan To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=f46d042ef5a34b344804d354d88a X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr-us4.tirtonadi.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - poluan.info X-Get-Message-Sender-Via: svr-us4.tirtonadi.com: authenticated_id: rileyer+pandu.poluan.info/only user confirmed/virtual account not confirmed X-Archives-Salt: 40e7bb98-7df6-4f62-9e0d-ebe9526d7f0d X-Archives-Hash: 8a3761a5e74b2d1edca272e7cecd3c3b --f46d042ef5a34b344804d354d88a Content-Type: text/plain; charset=UTF-8 On Jan 15, 2013 7:59 PM, "Alan McKinnon" wrote: > > On Tue, 15 Jan 2013 11:09:56 +0000 > Neil Bothwick wrote: > > > On Tue, 15 Jan 2013 11:57:21 +0200, Alan McKinnon wrote: > > > > > On the rare occasion when I reboot or shut this laptop down, it > > > continually and consistently gets stuck on one of the final steps, > > > to umount /home > > > > If you logout as your user(s) so only root is logged in, does lsof > > show any hits for /home? > > Only 1 hit - a background ssh process that sets up a bunch of tunnels > and port forwards so I can get into the corporate network for anywhere. > > But I was not able to make the problem re-appear in short reboot > cycles. So whatever is hanging the box is something that starts up in > the course of work, it doesn't appear to be there directly after a KDE > login. > > I might have to look at my work flow closely to find all those unusual > things I do in the course of work. I did manage to see the full > shutdown output on the screen with these tests though - it > umounts /home then umounts /boot, but the second umount message is > never displayed. Seeing as it's just a regular sdb1 partition using > ext2 I don;t really think it's getting stuck as the next step starts > up. It's more likely to have something to do with /home > > > > > > I had a similar problem with my MythTV backend failing to > > unmount /var. It turned out that mythbackend was failing to shutdown > > but openrc carried on trying to shutdown. If I make sure mythbackend > > really is stopped, the reboot proceeds normally, which is much better > > since I had to go into the loft to reboot the box manually, > > > > > > > > -- > Alan McKinnon > alan.mckinnon@gmail.com > > A bit roundabout, but you can also try making a 'pseudo-service'. Make it 'depend' on a late-stage service so it starts last, and shuts down early. The stop() part of the pseudo-service should perform an lsof >> a file (in a directory still available during the last throes of OpenRC like, say, /etc). I hope I'm making sense... Rgds, --f46d042ef5a34b344804d354d88a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jan 15, 2013 7:59 PM, "Alan McKinnon" <alan.mckinnon@gmail.com> wrote:
>
> On Tue, 15 Jan 2013 11:09:56 +0000
> Neil Bothwick <neil@digimed.c= o.uk> wrote:
>
> > On Tue, 15 Jan 2013 11:57:21 +0200, Alan McKinnon wrote:
> >
> > > On the rare occasion when I reboot or shut this laptop down,= it
> > > continually and consistently gets stuck on one of the final = steps,
> > > to umount /home
> >
> > If you logout as your user(s) so only root is logged in, does lso= f
> > show any hits for /home?
>
> Only 1 hit - a background ssh process that sets up a bunch of tunnels<= br> > and port forwards so I can get into the corporate network for anywhere= .
>
> But I was not able to make the problem re-appear in short reboot
> cycles. So whatever is hanging the box is something that starts up in<= br> > the course of work, it doesn't appear to be there directly after a= KDE
> login.
>
> I might have to look at my work flow closely to find all those unusual=
> things I do in the course of work. I did manage to see the full
> shutdown output on the screen with these tests though - it
> umounts /home then umounts /boot, but the second umount message is
> never displayed. Seeing as it's just a regular sdb1 partition usin= g
> ext2 I don;t really think it's getting stuck as the next step star= ts
> up. It's more likely to have something to do with /home
>
>
> >
> > I had a similar problem with my MythTV backend failing to
> > unmount /var. It turned out that mythbackend was failing to shutd= own
> > but openrc carried on trying to shutdown. If I make sure mythback= end
> > really is stopped, the reboot proceeds normally, which is much be= tter
> > since I had to go into the loft to reboot the box manually,
> >
> >
>
>
>
> --
> Alan McKinnon
> alan.mckinnon@gmail.com=
>
>

A bit roundabout, but you can also try making a 'pseudo-service'= . Make it 'depend' on a late-stage service so it starts last, and s= huts down early. The stop() part of the pseudo-service should perform an ls= of >> a file (in a directory still available during the last throes o= f OpenRC like, say, /etc).

I hope I'm making sense...

Rgds,

--f46d042ef5a34b344804d354d88a--