OK, let's make a resumé: (it should be an executive summary, but I'm too wordy, sorry)
The problem happened on some boxes and someone did it home work and concluded that the issue was due to the 'alt-f-utils' updated pkg; when the update was removed, the problem disappeared. I continued it work and concluded that the culprit was the dns320l-daemon process.
First notice the program name, dns320l-daemon, i.e. it is meant to work on a DNS-320L box. More on that latter.
There is nothing wrong with the program itself, it works fine for me on a DNS-320L or a DNS-327L box, the issue seems to be a conflict between the flash-resident program and the disk-updated program. When I was able to reproduce the problem, I noticed that killing the running dns320l-daemon and waiting for 'init' to relaunch it (more on that latter) the problem went away. So I devised the user boot script to do the same. The user boot script runs when the disk/filesystem where it is stored is discovered. It does not need to be the disk/filesystem where the Alt-F packages are installed, but I advised to store it in the same filesystem. Why?
Some inside trading: the dns320l-daemon is launched by 'init' through /etc/inittab, not as a service. it was done this way so it would be automatically relaunched if any problem with it arises, as it is required to, e.g., power down the box. As this happens earlier in the boot process, even before disks/filesystem are discovered and mounted, the dns320l-daemon is already running from flash when the Alt-F disk/filesystem is discovered and starts being used; then, the updated on-disk dns320l-daemon takes priority over the running one from flash, and the conflicts arises. With normal packages this does not happens, as all on-disk updated pkgs/services are stopped and then started (restarted) though its init scripts.
Now you have mostly all elements to understand the problem: there is a need to stop the flash-running dns320l-daemon. The user boot script does that but in a flawed way, thanks to the "make it fast and cheap" paradigma. It should wait for the Alt-F folder to have been discovered and put in use.
How can that be done? Using the 'aufs.sh -s' command -- it prints OK and returns 0 when the Alt-F folder is in use, so a '
while ! aufs.sh -s; do usleep 100000; done' before the killall stanza
I posted before does it. But what if the Alt-F folder does not come up, for whatever reason? Damaged disk, fsck running, USB stick removed... to prevent that, the user init script (/etc/init.d/S99user) is the last one being started and the user boot script is launched by it in the background, so if it never accomplish no big harm happens -- but other issues might come along.
Now, what does the dns-320l-daemon process has to do with power down? D-Link put a new chip in the motherboard of the DNS-320-rev-A, but with limited usage -- it just measures the system temperature, and to read it a special script exists: /usr/sbin/dns320-temp.sh. With the DNS-320-rev-B and later models (DNS-320L, DNS-327L), that chip reads not only the temperature but also controls the fan, leds, powerdow, etc, so the dns320l-daemon is needed. A. Böhlr initially wrote it, see
Credits, and I latter continued his work.
So, if you don't have one of those box models you don't have power down problem and you don't need the user boot script for that purpose.
BTW, there isn't differently crafted /etc/inittab for the different boxes, it is /etc/init.d/rcS (that is launched by 'init') that identifies in which box is it being run, comments out /etc/inittab entries, and signals 'init' of the changes.
And what about the readiness of all disks and the Alt-F folder? When I first started Alt-F on the DNS-323, I was constantly swapping and hot plugging disks, it is very easy to do that on that box (and on the DNS-325). So the system never knows how many disks it should have and where they are located -- left bay? right bay? USB SATA adapter? USB disk? No disk at all? and it has to live with it. The same for the Alt-F folder, the user might not have installed any Alt-F package, or a fsck might be running, or whatever. So the system has to work out as it is in the current moment. Android has/had a similar problem with user-inserted or removed SD-cards.
Conclusion:
Experient linux users can use the above, experiment by themselves, report their findings and devise a definitive solution. Un-experimented users have to wait for experienced users findings. That's the status of support currently, don't wait for me to solve issues, help yourself. I'm however ready to clarify, help and advise, as I'm doing now.
I'm still working on and with Alt-F but don't have the time or motivation to answer "HELP me" laconic and information missing requests. This should be top-posted -- ah, no sticky posts exists, I have still to turnaround that Google "group" misfeature!