No entiendo lo que me quieres decir. No pregunto si puede correr como demonio sino cómo configurarlo correctamente ya que, como servicio, la configuración debería ir por un lado y los datos por otro. El problema es que instalo MLD vía Slackbuilds y al menos aquí no trae un script de inicialización, el cual he sacado de Slacky.eu.
No hay nada como leer detenidamente, acabo de encontrar esto:
[...] you can change the path /home/mldonkey ( by example /var/mldonkey if you have a big /var partition for apache, ftp... ).
(Fuente: (link roto)
MLDonkey is a badly-behaving program for an unixish environment in that sense that it expects to find it's configuration and state files from it's current work directory. In the unix-world, this is not the way to do things. Configuration files ought to reside inside the /etc directory structure, and state in /var, and for locally installed programs that are not thought of to be a part of the operating system itself, the respective directories are /local/etc and /local/var.
Since version 2.6.1 MLDonkey stores its files in $HOME/.mldonkey
Putting ini files in /etc and data in /var is not that easy because on a server system there can be several MLDonkey daemons working by different users.
Note that the "current work directory" is not the same thing as path of the executable file itself; for example when running the ls program from /bin/ls while in directory /foo/bar, the work directory of the program is /foo/bar, not /bin.
Solutions
Re-design the MLDonkey's idea of where to store filesLike said, expecting to find or create configuration and state files in the current work directory is not the usual way to do things in the unix-world.
Also no clear distinction between state and configuration exists in the core design, or phrased another way, the configuration is a set of parameters of the core state. Thus every time the state is saved, either by automatically every now and then (every 11 minutes, I think), or manually with the save command by the user, the configuration files are also (unconditionally) overwritten. Thus all configuration of the core must be made through an interface to the core itself, not by fiddling with the configuration files themselves if there modifications are expected to last.
(Fuente: (link roto)
Y es que no había caído en esta situación. No tengo una partición dedicada para /var y la raíz es bastante limitada por lo que tendría que separar el directorio temp a la partición /home. Estaría en las mismas: el directorio .mldonkey por un lado, incoming y temp por otro, cuando sólo quería dejar incoming en /home. Además, por lo que entiendo del artículo, no es tan fácil separar las configuraciones en /etc y /var aunque no entiendo muy bien la causa:
Putting ini files in /etc and data in /var is not that easy because on a server system there can be several MLDonkey daemons working by different users.
Servicios sólo habría uno corriendo como el usuario dedicado y no uno por cada usuario, claro que, el problema puede residir en el choque de configuraciones si otros usuarios ejecutaran el archivo bin.
Al menos parece que tener la configuración en /home no se sale de lo común para MLD aunque genéricamente no sea lo propio en los entornos GNU/Linux. Por otro lado, me quedo con la duda: ¿qué diferencia existe entre un usuario normal y del sistema?
Pues nada, ahí lo dejo, cualquier aclaración o corrección es bienvenida. ;)
