On 11 June 2017 at 17:06, Bruce Dubbs <[email protected]> wrote:
> Richard Melville wrote:
>
>>
>>
>> On 10 June 2017 at 20:41, Bruce Dubbs <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Bruce Dubbs wrote:
>>
>> Thomas Seeling wrote:
>>
>> Hallo,
>>
>>
>> I seem to have a serious misunderstanding how SysV init works
>> ...
>> After building NFS support I could happily mount NFS
>> filesystems from my
>> NAS.
>>
>> Then I did a reboot and noticed that the sequence of kill
>> scripts is a
>> bit ... unfortunate to say the least.
>> First it removes the IP address from the network interfaces
>> and only
>> *then* it tries to unmount the "rest" of the filesystems.
>> This does not work for NFS though - it hangs forever.
>>
>> So I wrote a special kill script to unmount NFS and put it
>> *before* the
>> kill script for the interfaces.
>> This works fine and I was happy.
>>
>> At least for a short time - until I used the "poweroff"
>> command and
>> noticed that once again the sequence is not correct.
>>
>> I thought the logic behind poweroff and reboot is the same but
>> obviously
>> there are different code paths.
>>
>> Can somebody clue me in what I'm doing wrong?
>>
>> Here are my init scripts as far as network and NFS are
>> concerned:
>>
>> /etc/rc.d/init.d/:
>> mountfs
>> mountnetfs
>> network
>> nfs-client
>>
>> /etc/rc.d/rc3.d/:
>> S20network
>> S30rpcbind
>> S31nfs-client
>>
>> /etc/rc.d/rc6.d/:
>> K30nfs-client
>> K30rpcbind
>> K45mountnetfs
>> K80network
>> S99reboot
>>
>>
>> For poweroff, the sequence needs to be defined in
>> /etc/rc.d/rc0.d/.
>>
>> One of the boot scripts may need a minor correction. We don't use
>> nfs a
>> lot so we might have a problem with shutdown.
>>
>> The stop portion of mountfs does:
>>
>> umount -a -d -r -t notmpfs,nosysfs,nodevtmpfs,noproc,nodevpts
>> >/dev/null
>>
>> Try adding a -f switch to that to force the umount when the
>> network is
>> down. In the meantime I'll think about a cleaner way to do the
>> network
>> umounts. Perhaps the best place would be in the network stop
>> script and add
>>
>> umount -a -f -O _netdev >/dev/null
>>
>> But that will not handle any network mounts that are not in fstab.
>>
>> Any testing and feedback you can give will be appreciated.
>>
>>
>> When considering network mounted filesystems we need to consider nfs,
>> sshfs, and smb (samba) mounts. One thing all these have in common is
>> that the mounted device (first entry) in /proc/mounts has a colon
>> specifying the host.
>>
>> Adding the following to the *network* script should umount all these
>> files.
>>
>> stop)
>> # Unmount any file systems mounted over the network
>> # Read /proc/mounts and look for a colon in the first field
>> for device in `cut -d" " -f1 /proc/mounts|grep :`; do
>> umount -f $device 2>$1 >/dev/null
>> done
>> ...
>>
>> What do you think?
>>
>>
>> I think that backticks are difficult to read, as opposed to $().
>>
>
> $() is specific to bash. We try to keep the boot scripts Bourne Shell
> compatible. I agree that $() is generally preferable, but not here.
Bruce, thanks for your answer. I wasn't going to reply as it seems a
little like nit-picking, but, as {,B}LFS is primarily an educational
resource, I felt that your statement needed correcting, for the benefit of
newcomers. They would be led to believe that they could not use $() for
any shell other than bash, but $() isn't a construct that's "specific to
bash". AFAIK all modern shells can use that command substitution
construct. Indeed, bash borrowed the construct from the Korn shell is the
first place. I can understand your desire for backwards compatibility, but
"Bourne Shell compatible" seems to me to be taking things a little too
far. Besides, the $() construct is Posix compatible.
Richard
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
