Es ist wichtiger und richtiger sich an etablierte standards/konventionen für "Unix-ähnliche" Betriebssysteme zu halten, als was Leute "gefallen". Im Tuxboxprojekt hat sich leider einige eigensinnige (Un-)Sitten entwickelt.
Es existiert der
Filesystem Hierarchy Standard (FHS). Es ist nicht wünschenswert, dass jede Projekt eigene Filesystemsemantik entwickelt.
Einige Auszüge:
/mnt : Mount point for a temporarily mounted filesystem
Purpose
This directory is provided so that the system administrator may temporarily mount a filesystem as needed. The content of this directory is a local issue and should not affect the manner in which any program is run.
jmittelst Vorschag zu Mountpunkt (sowie (Un-)Sitten die leiter etwas verbretet sind) ist also nicht FHS-konform.
/var contains variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files.
/etc : Host-specific system configuration
Purpose
The /etc hierarchy contains configuration files. A "configuration file" is a local file used to control the operation of a program; it must be static and cannot be an executable binary. [4]
Konfigurationsfiles gehören also in /etc, nicht in /var. (Konzeptionell, dass (oft) nur /var bescreibbar und /etc ein symlink ist, ist eine andere Sache.)
/var/run : Run-time variable data
Purpose
This directory contains system information data describing the system since it was booted. Files under this directory must be cleared (removed or truncated as appropriate) at the beginning of the boot process. Programs may have a subdirectory of /var/run; this is encouraged for programs that use more than one run-time file. [42] Process identifier (PID) files, which were originally placed in /etc, must be placed in /var/run. The naming convention for PID files is <program-name>.pid. For example, the crond PID file is named /var/run/crond.pid.
Eine Versetzung von .pid-Files nach /tmp ist also nicht FHS-konform.
jmittelst hat geschrieben:P.S. Was ich noch nicht ganz verstanden habe: Wozu ist eigentlich /var/lock gut?
Das Verzeichniss ist in FHS bescrieben. Es wird (IIRC) ein lock-file für /etc/mtab abgelegt, was eigentlich etwas daneben ist.
@mb405: Die Signalhandling ist in manpage automount.8 beschrieben. Siehe auch meine Kommentarein am Anfang von start_automount. Hier ein Auszug von automount.8:
If the automount daemon catches signal USR1, it will unmount all cur-
rently unused autofs-mounted filesystems and continue running (forced
expire). If it catches signals TERM or USR2 it will unmount all unused
autofs-mounted filesystems and exit if all filesystems were unmounted.
Busy filesystems will not be unmounted. The daemon also responds to a
HUP signal which triggers an update of maps for which ghosting is
implemented (currently FILE and NIS maps).
If the autofs directory itself is busy when the daemon is signalled
with an exit signal then the daemon will exit without unmounting the
autofs filesystem. The filesystem is left in a catatonic (non-func-
tional) state, and can be unmounted when it becomes unused.
Weil der automounter nicht Neutrino gehört, und auch für z.B. Enigma-benutzer von interesse ist, ist ein Aufruf aus rcS das Richtige, nicht aus start_neutrino.