'a start job is running...'

Hace unos meses, durante el arranque de mi ordenador (pero curiosamente solo en el de sobremesa...) se me paraba durante cerca de 1 minuto con el mensaje

'a start job is running for create volatile files and directories' 

(o algo así). Y luego continuaba normalmente el arranque. Investigando un poco por Google, se mencionaba este caso, pero las soluciones que se daban (que si el grub, que si la swap...) eran vagas, y no me funcionaron.
Pero antes de nada, voy a recomendar leer el APÉNDICE que puse, más tarde, al final, sobre otro caso de 'a star job is running...' porque es muy interesante y me topé con él en más de una ocasión.
Ahora, volviendo al caso inicial, un día (hace poco) logré solucionarlo (a lo burro, luego cuento cómo), y desde entonces no me ha vuelto a suceder.
Pero anteayer, en el foro de EspacioLinux, dos estupendos foreros, enriquehh y cargoan impartieron una clase magistral sobre cómo resolverlo, y como siempre he dicho que este blog es el 'repositorio' de mis apuntes, voy a extractar aquí las posibles soluciones dadas al tema... que al parecer funcionan.
Parece ser que el problema procede de la adopción del nuevo demonio de administración del sistema, el famoso systemd, que recientemente se ha elegido (no sin polémica entre gurús) por sus ventajas sobre el clásico 'init', etc. Y el caso es que estas son las posibles soluciones:
Solución 1 – la fuerza bruta
Así lo solucioné yo: como mi sobremesa llevaba mucho tiempo con varias particiones adicionales (para probar otras distros, etc) que nunca tocaba, y que tenían enlaces simbólicos a mi /home principal, harto de pruebas, una tarde tonta, y con la ayuda de un buen disco duro externo, formateé (borré) todo el disco del PC, volví a crear particiones, instalé desde 'cero'... y luego repuse mis archivos.
Mano de santo: desde entonces no me ha vuelto a aparecer el problema.Y espero que así continúe.

Solución 2 – engañar al servicio systemd-tmpfiles-setup.service
Esta es la solución a la que llegó, empíricamente, enriquehh. Parece ser que este servicio es el encargado de crear los archivos temporales, con las instrucciones que recibe de los archivos de configuración que se encuentran en el demonio /usr/lib/tmpfiles.d
Entonces el 'apaño' consiste en crear una serie de archivos, en blanco, con el mismo nombre que los que están en /usr/lib/tmpfiles.d, en el demonio /etc/tmpfiles.d. Y se le engaña porque este demonio (en /etc/...) tiene 'prioridad' sobre el otro, en /usr/lib/...
Por tanto, lo primero es listar los archivos (*.conf) que tenemos en /usr/lib/tmpfiles.d, con
ls /usr/lib/tmpfiles.d
y ahora los creamos, en blanco (por supuesto, todo esto se hace, en consola, con privilegios de root), con
cd /etc/tmpfiles.d/
Y creamos los archivos en blanco simplemente con el comando 'touch', así:
touch x11.conf legacy.conf tmp.conf systemd-nologin.conf
(esto suponiendo que estos son los archivos *.conf encontrados). El amigo enriquehh comenta que él dejó sin poner en blanco estos 3 archivos: debian.conf, systemd.conf y var.conf. Dice que no hacía falta, que lo solucionó con el resto. Bueno...) 
Y, reiniciando... solucionado.
NOTA 1: también comenta que antes de nada, conviene verificar el archivo fstab y comprobar si la partición swap esta correctamente configurada (esto puede solucionar también el problema por creación de archivos temporales en el arranque de Debian
NOTA 2: en systemd parece ser que, como método más ortodoxo que el de poner archivos en blanco, es el crear los correspondientes enlaces a /dev/null con la orden (como root)...
ln -s /dev/null /etc/tmpfiles.d/nombre_archivo.conf
así que puede ser más recomendable hacerlo así
NOTA 3: y si ves que no funciona, basta borrar los archivos creados en blanco (o los enlaces a /dev/null). Como root, claro.

Solución 3 – recrear los temporales
Como parece ser que el problema está en /tmp, una forma de solucionarlo sería borrar /tmp, y recrearlo.
Esta es la solución que propuso cargoan, pero atención, que tiene varios matices importantes: para hacerlo, hay que entrar en el 'modo emergencia', que es un modo mucho más restrictivo que el más conocido 'recovery mode', porque inicia con lo mínimo, y sin ningún servicio (en recovery mode, por ejemplo, se monta el /tmp como tmpfs, y no serviría). 
Así que hay que hacerlo así:
a) al arrancar, en la pantalla del GRUB, pulsar 'e' (editar)
b) ya editado, añadir, al final, la siguiente línea
rw systemd.unit=emergency.target
c) teclear EXIT (o reiniciar) y ya arranca en 'modo emergencia'. Entonces, ahí teclear, como root
rm -rf /tmp
mkdir /tmp
chmod 1777 /tmp
(o sea, borrar el /tmp, y crearlo de nuevo, dándole los permisos oportunos)
d) Y, ahora, volver a reiniciar el ordenador, ya con el /tmp limpio. Y, al parecer, se soluciona el problema.
(por cierto, preguntaba yo si, después de esto, había que volver a editar el GRUB y borrar la línea añadida, pero me comentan que no hace falta, que esos cambios no son persistentes (son solo para ese arranque), así que no hace falta. Pues estupendo)


Y acabo. Yo no he probado nada, porque realmente ya no tengo este problema del 'a start job is running...' pero debo decir que, al final, se convino lo siguiente: probar, primero, la Solución 3 y, solo si no funciona, probar la Solución 2.
Y bueno, para los novatos como yo, si ninguna de ellas funciona... probar la mía, la de la fuerza bruta. O sea... actuar por las bravas, formateando todo.

NOTA AÑADIDA:  
Unas semanas más tarde, leí esto en un foro de Manjaro:
"Bueno pues la solución que hemos probado con éxito varios usuarios es abrir con privilegios de root el navegador de archivos que uséis, en mi caso con gnome fue con gksu nautilus, pero también tuvo este problema un usuario con Kde, y borrar el contenido de la siguiente carpeta:
/usr/lib/tmpfiles.d
(borrar los archivos de dentro de la carpeta, no la carpeta, claro).
Por lo que he leído es un fallo de systemd que os puede ocurrir, no solo en manjaro sino que también he leido que ha sucedido en debian".
(así que aquí lo dejo apuntado, por si pudiese funcionar)

APÉNDICE
Días más tarde, y en un pequeño portátil (EeePC) que tengo me saltó un mensaje (y consecuente parón de minuto y medio) similar. Era este:

a start job is running for dev-disk-by/x2duuid/c54c0181/x2d8138/x2d4377/x2dba3f/x2d61960...

pero el problema era distinto: pronto descubrí que esta vez se debía a una incongruencia entre el /etc/fstab y el UUID real de una partición. Pero... ¿cual? porque esos números no me sonaban a ninguna, ni incluso haciendo el típico
ls /dev/disk/*
me salía nada parecido a esa retahila de números.
Y de nuevo mis amigos foreros salieron a mi rescate porque, si se hace...
systemctl list-units --all | grep dev-disk | awk '{print $1}'
la consola te saca una lista enorme y, al final, compruebo que systemd ha llamado así... a mi partición SWAP.
(Efectivamente, acababa de instalar una segunda distro en ese portátil, un Manjaro, formateando la SWAP (e incluso hecho después, para reformatearla, un
sudo mkswap /dev/sda6  (en mi caso) seguido de un...  
sudo swapon /dev/sda6 para volverla a montar)
así que pronto descubrí que esa fue la causa ¡De nuevo systemd...!
y es que parece ser que cuando se formatea una partición (sobre todo ésta) puede haber riesgo de que cambie su UUID.
Así que la solución fué sencilla:
sudo blkid
para saber cual es el UUID actual de mis particiones (en particular la SWAP), y
sudo nano /etc/fstab
para editar el fstab, y corregir el nombre, que efectivamente había cambiado.

Y otra vez me volvió a arrancar perfectamente, sin pausas, y sin el mensajito de marras.