Re: debian startup scripts & dedicated ppp
On Tue, 24 Sep 1996, Joey Hess wrote: > > You should propagate the PPP startup script before the NFS > > mounts occur. This is a site specific configuration that > > probably isn't that common. Never the less, I think Debian > > 1.2 will probably deal with this better (I think). In the > > I hope so. I didn't have much trouble getting the nfs stuff working, but > I didn't like what I had to do and I felt it should work better out of the > box without requiring editing of the rc scripts. Well, I don't know about that. I can't get ppp working under Solaris without editing the asppp scripts and creating a startup script, etc. Of course, Debian is better than Solaris :-) I know that Bruce plans on including some kind of ppp configuration utility in 1.2 that would produce a chat or diald script. It shouldn't be too difficult to add the functionality of choosing where to place it in the startup. Most people don't have a "full time" ppp connection AFAIK. I believe the average ppp user only connects when she/he needs to and works "offline" the rest of the time. I could be wrong though. Slackware has a section of its installation that sets up NFS mounts. Maybe Debian should look into including something like this too? Maybe it has it and I forgot? > > > system in front of me right now (mine's floating in the > > Pacific at the moment :-)), so this is the best I can do. > > This should get your ppp up prior to going to the mount > > phase. > > Are you the guy who's doing data collection with a underwater linux > system? I think that'd make a great Linux Journal article :-) No, I'm the guy who just moved overseas and doesn't have any of his stuff because its being shipped via ocean liner. My wife and I both pulled a smooth move and packed up all of our shoes (except the ones we were wearing when the movers came). As much as I miss my Debian system, we can't wait to get our shoes! (It should be noted here that my wife does _not_ miss my Debian system ;-)) > > I think Solaris 2.5+ has a functional fuser command > > that could be used to kill all processes (close all open > > filehandles) on a mount point. The shutdown procedure could > > then kill processes on NFS mounted filesystems first, > > unmount NFS filesystems, then do its normal routine of > > killing all processes and umounting all filesystems. > > > > Anybody know if Debian's fuser command supports this? > > Anybody got any other ideas here? > > It looks like fuser will support this, it has a -k flag that will kill all > processes accessing a file. fuser -m -k /home should kill every process > using the /home partition. Well, I'd have to have a Debian system running to do some testing, and we'd have to have a way of dealing with automounted filesystems (addressing the correct mount point), but it looks like we should be able to implement a shutdown procedure that takes care of NFS mounts prior killing all processes. If you're interested in pursuing this, please e-mail me privately. I'd be glad to try to implement something and submit it for inclusion in later Debian releases (unless someone already has :-)). Thanks. Richard G. Roberto [EMAIL PROTECTED] 011-81-3-3437-7810 - Tokyo, Japan -- *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. ***
Re: debian startup scripts & dedicated ppp
> You should propagate the PPP startup script before the NFS
> mounts occur. This is a site specific configuration that
> probably isn't that common. Never the less, I think Debian
> 1.2 will probably deal with this better (I think). In the
I hope so. I didn't have much trouble getting the nfs stuff working, but
I didn't like what I had to do and I felt it should work better out of the
box without requiring editing of the rc scripts.
> system in front of me right now (mine's floating in the
> Pacific at the moment :-)), so this is the best I can do.
> This should get your ppp up prior to going to the mount
> phase.
Are you the guy who's doing data collection with a underwater linux
system? I think that'd make a great Linux Journal article :-)
> This seems to be a very popular problem. Debian, RedHat,
> Slackware, SunOS, Solaris, Irix all kill all processes prior
> to unmounting filesystems. The theory behind this is that
> if a filehandle is open on a filesystem, it can't be
> unmounted. The problem is when the process killed is ypbind
> or pppd and you can't resolve the hostname of the NFS
> server.
I did like redhat's solution; it worked for me, but I can think of
situations where it wouldn't..
> I think Solaris 2.5+ has a functional fuser command
> that could be used to kill all processes (close all open
> filehandles) on a mount point. The shutdown procedure could
> then kill processes on NFS mounted filesystems first,
> unmount NFS filesystems, then do its normal routine of
> killing all processes and umounting all filesystems.
>
> Anybody know if Debian's fuser command supports this?
> Anybody got any other ideas here?
It looks like fuser will support this, it has a -k flag that will kill all
processes accessing a file. fuser -m -k /home should kill every process
using the /home partition.
> > I see that red hat uses a "nfsfs" script that's responsible for
> > starting/stopping nfs services at the appropriate time. Unless I'm just
> > totally missing something with my problems as I described them above, I
> > propose that a similar script be added to debian.
>
> How does this script handle the open filehandles issue on
It doesn't handle them at all. The key thing is, it's a standard sysv init
script, so the sysadmin can change the order it's executed in my changing
the symlink, and so can ensure that anything else that's using the nfs
mounts gets killed before the script is executed. (In theory, anyway.)
> Do you have a copy of the script?
Here's a copy of the script:
#!/bin/sh
#
# nfsfs Mount NFS filesystems.
#
# Version: @(#) /etc/init.d/skeleton 1.01 26-Oct-1993
#
# Author: Miquel van Smoorenburg, <[EMAIL PROTECTED]>
#
# Source networking configuration.
. /etc/sysconfig/network
# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0
# See how we were called.
case "$1" in
start)
echo -n "Mounting remote filesystems."
mount -a -t nfs
touch /var/lock/subsys/nfsfs
echo
;;
stop)
echo -n "Unmounting remote filesystems."
umount -a -t nfs
rm -f /var/lock/subsys/nfsfs
echo
;;
*)
echo "Usage: nfsfs {start|stop}"
exit 1
esac
exit 0
--
#!/usr/bin/perl -lisubstr($_,39+38*sin++$y/9,2)=$s # [EMAIL PROTECTED]
for($s=' '||McQ;$_='JOEY HESS 'x8;print){eval$^I} # Joey Hess
"He. He. He." - - Herman Toothrot
Re: debian startup scripts & dedicated ppp
On Mon, 23 Sep 1996, Joey Hess wrote: > I have a dedicated ppp script, and it doesn't seem that debian's startup > scripts make any provisions for this. I've modified the init.d/ppp script > to start up ppp, and made it be run on boot and shutdown. > > There's a filesystem I always nfs mount over ppp (it's in fstab), and when > I'm booting up, init.d/boot mounts all the nfs filesystems after it's run > init.d/network, but before my ppp gets started. So I have to wait there > until the mount times out, and manually mount the filesystem after the > system is done booting. You should propagate the PPP startup script before the NFS mounts occur. This is a site specific configuration that probably isn't that common. Never the less, I think Debian 1.2 will probably deal with this better (I think). In the mean time, you can customize the init.d/network script to call your ppp startup script instead of running it out of rcX.d (where X is the run level). I don't have a Debian system in front of me right now (mine's floating in the Pacific at the moment :-)), so this is the best I can do. This should get your ppp up prior to going to the mount phase. A better solution may be to use the noauto option for NFS mounts and include a separate NFS mount script in init.d and link it to something later than the PPP script in the rc directory. That would save you from modifying init.d/network. It would also enable you to configure runlevels that do not use ppp, or NFS mounts, etc. Again I don't have a Debian system in from of me right now, so I don't know how this is handled in 1.1 out of the box for sure. > > I have a similar problem on shutdown, my ppp is killed when the scripts in > /etc/rc6.d are run, but the nfs filesystem is still mounted. Then > init.d/reboot comes along and tries to unmount filesystems, anf gets hung > up on the nfs filesystem, and I have to wait for that to time out before > my system reboots. This seems to be a very popular problem. Debian, RedHat, Slackware, SunOS, Solaris, Irix all kill all processes prior to unmounting filesystems. The theory behind this is that if a filehandle is open on a filesystem, it can't be unmounted. The problem is when the process killed is ypbind or pppd and you can't resolve the hostname of the NFS server. I think Solaris 2.5+ has a functional fuser command that could be used to kill all processes (close all open filehandles) on a mount point. The shutdown procedure could then kill processes on NFS mounted filesystems first, unmount NFS filesystems, then do its normal routine of killing all processes and umounting all filesystems. Anybody know if Debian's fuser command supports this? Anybody got any other ideas here? > > So is there a better way to set up a dedicated ppp link than what I'm > using? And is there any provision to unmount filesystems before the > network is brought down? > > I see that red hat uses a "nfsfs" script that's responsible for > starting/stopping nfs services at the appropriate time. Unless I'm just > totally missing something with my problems as I described them above, I > propose that a similar script be added to debian. How does this script handle the open filehandles issue on NFS mounts? Do you have a copy of the script? Thanks Richard G. Roberto [EMAIL PROTECTED] 011-81-3-3437-7810 - Tokyo, Japan -- *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. ***
Re: debian startup scripts & dedicated ppp
The simple solution to your problem is to put the 'noauto' option on your nfs directory entry in /etc/fstab, and then put an explicit mount command (and corresponding umount command) in the init.d/ppp script. You could also setup amd, but that could be overkill for your situation. -- Scott Barker Linux Consultant [EMAIL PROTECTED] http://www.cuug.ab.ca:8001/~barkers/ (under construction) [ I try to reply to all e-mail within 3 days. If you don't ] [ get a response by then, I probably didn't get your e-mail. ] [ Unsolicited commercial and junk e-mail will be proof-read for US$100 ] "There is a coherent plan in the universe, though I don't know what it's a plan for." - Fred Hoyle
debian startup scripts & dedicated ppp
I have a dedicated ppp script, and it doesn't seem that debian's startup scripts make any provisions for this. I've modified the init.d/ppp script to start up ppp, and made it be run on boot and shutdown. There's a filesystem I always nfs mount over ppp (it's in fstab), and when I'm booting up, init.d/boot mounts all the nfs filesystems after it's run init.d/network, but before my ppp gets started. So I have to wait there until the mount times out, and manually mount the filesystem after the system is done booting. I have a similar problem on shutdown, my ppp is killed when the scripts in /etc/rc6.d are run, but the nfs filesystem is still mounted. Then init.d/reboot comes along and tries to unmount filesystems, anf gets hung up on the nfs filesystem, and I have to wait for that to time out before my system reboots. So is there a better way to set up a dedicated ppp link than what I'm using? And is there any provision to unmount filesystems before the network is brought down? I see that red hat uses a "nfsfs" script that's responsible for starting/stopping nfs services at the appropriate time. Unless I'm just totally missing something with my problems as I described them above, I propose that a similar script be added to debian. -- "true - do nothing, successfully" - - true (1)
