Sorry, I don't use ARM. <-- The only barriers that can stop you are the ones you create yourself. <--

Actually, this is a universal TCL issue (x86/x64/etc.) and there's a hanging problem across distros when shutting down (where mounts fail dismounting for numerous reasons and hang up at either SYNC or UMOUNT -A due to a known issue in nfs-utils... though I think I've come across an easy-enough fix, at least within rc.shutdown, which thus far has been working like a charm but in order to make rc.shutdown more stable with remote mounts (cifs, nfs, AoE, etc.) it would require a little reworking of /etc/init.d/rc.shutdown and a few self-checks implemented with the following logic:

*Attempt to WRITE to a dummy file on each remote mount - many of them may have sleeping hard drives, delete the file afterward

First, SYNC and then scan 'mount' for remote mounts and dismount each manually, NOT with umount -a

Next, SYNC and then kill running processes as some of these may leave the above rule open with file locks

Repeat the first step if any mounts are found left within the list from 'mount'

At this point, we've exhausted logistics, force a dismount of remote mounts and allow rc.shutdown to continue

In most cases/distros, when umount -a fails/hangs on a remote mount, there's a two minute timeout which is a while to wait, but not forever... but it still leaves the possibility for unwritten data and/or other similar means for corruption. The above logic helps with this a bit, but with remote mounts there's nothing I can think of which covers 100%.

Combination to prevent remote shares from hanging up during shut-down seems complete.This has been tested in a LAMP environment where all services were operating during the shutdown/reboot request.Bare in mind, I left a few notes here and there for visual aid while testing; the scripts could use a bath and minor efficiency rewrite.

In /etc/init.d/tc-config immediately before extensions are loaded, add:

I have not proven my theory yet, but I have reason to believe, based on the complaints regarding nfs-utils I've read, there's a good chance umount -a doesn't play nice with mount.nfs and based on the order in which rc.shutdown starts off, we may be asking NFS to dismount prior to file handles being released (guaranteed for /tmp/tcloop), or for all I know we could be dismounting extensions (including nfs-utils??) prior to NFS shares being let go which I'm guessing could also cause issues.

When TCL is running with nfsmount=server:/share and tce=nfs, without the above mods rc.shutdown will hang at the point it tries to umount -a for a few minutes, with the above there's virtually no delay at all. All other network shares, especially those where TCL is allowed to persist onto the share, need to be treated in the same fashion to prevent lags/hanging as well as help prevent data loss/corruption.

@juanito: Thanks! I cannot speak for x86/x64 as I haven't repeated this process there yet, but it may be prudent to add libcap.tcz to nfs-util's dependency list.

@curaga: YES, PIDs are reused, the concept here is to TRY and avoid start-up processes (take DHCPc for example) from getting shut down TOO early (we don't want anything interrupting networking while attempting to disconnect from our shares in this case) so setting a land-mark (ie: don't kill off anything prior to when our extensions were being loaded) sounded like a potentially safe bet for processes which don't reinitialize themselves. TCL may be a little too mature to begin a new standard, such as implementing init's for daemons... but who knows!

I'm planning on putting together an add-in for rc.shutdown which scans init.d directories and calls scriptnamestop for launch scripts it can find and then go against popular apps (such as apache, sql, etc.) and if running, call their associated binaries to shut down naturally (as opposed to SIGs) to assist with some of the killings and potential data issues. Considering the lack of standardized init scripts within many of the extensions, it's the easiest way I can think of (and an ongoing list over time).

For my needs (which are uncommon versus the community's usual use for TC) I have a "profile" set up for website design, for example, which is a general LAMP configuration and a hand-full of extensions (ionCube, DAV, SVN, etc.) which I'm going to package as my_lamp.tcz which will include init's and other basic content to simplify what's needed here; you're welcome to the init's when they're done if you think they'd be useful.

nfs-utils.tcz Version 1.3.3 I have not read up on as of yet, but from the .info notes, rpcbind.tcz is a replacement for portmap; if this has rpc.statd in the same locations and the likes, please replace portmap.tcz from the dependency listing accordingly (otherwise there are going to be needs in tc-config no longer being met which will make the boot code nfsmount= dysfunctional )

@juanito:AS-IS, NFS has commands hard-coded into tc-config and thus failed by simply replacing it with the one you've just built. First, there are (expected) complaints about the calls to the now missing portmap, tcp_wrappers, etc. called in tc-config:nfsmount and then when etc/init.d/nfs-client is called, it says it's launching and then hangs for a few minutes (see time stamps):

That's what I thought of as well, but the first thing I did was run a search for the provider of the missing file, ran tce-ab to install it... and it indicated it was already installed. From the looks of things, there's merely a symlink needed between so.3 to the existing @so.1 which libtirpc installs.

These are fresh remasters (for the time being, the TCZ files are being stored in /etc/embed instead of extracted into the image just to speed along testing and rebuilding - there's no MyDATA and without NFS functioning correctly, there's no persistent NFS shares for TCE/OPT, however I'll manually launch an update to the local repo here just in case there are files in limbo.

tc-config updated to accommodate both the old and the new nfs-utils/dependencies (tce.installed calls as the extensions are intended to be embedded if/when using nfsmount= boot code) in the following order: