Cómo iniciar WSL y una distribución Debian al arrancar Windows 11 sin necesidad de inicio de sesión
Uno de los mayores quebraderos de cabeza al usar WSL2 como parte de una infraestructura "always-on" —por ejemplo, para tareas de sincronización, backups o servicios ligeros en Linux dentro de un equipo Windows— es que, por defecto, WSL solo arranca cuando un usuario inicia sesión de forma interactiva. En escenarios donde el equipo debe funcionar de forma desatendida (un NUC, un servidor doméstico, una máquina remota a la que se accede por RDP de forma esporádica), esto es un problema: si nadie hace login, WSL simplemente no está disponible.
La solución pasa por el Programador de tareas de Windows, configurado para ejecutar wsl.exe en el arranque del sistema, sin depender de una sesión de usuario. A continuación se explica cómo montarlo correctamente, y qué limitaciones hay que tener en cuenta.
El script de arranque
Aunque es posible apuntar la tarea directamente a wsl.exe, es más robusto envolver la llamada en un script (.bat o .ps1), por ejemplo:
wsl -d Debian -u root -- /bin/trueEsto da un punto donde añadir logging o lógica de reintento si en el futuro algo falla silenciosamente.
Configuración de la tarea
La tarea debe crearse desde el modo avanzado del Programador de tareas (taskschd.msc), no desde el asistente básico, porque se necesitan tres ajustes que este último no expone:
- General: marcar "Ejecutar tanto si el usuario ha iniciado sesión como si no" y "Ejecutar con los privilegios más altos", asociando la tarea a una cuenta con perfil ya creado en la máquina.
- Desencadenador: "Al iniciar el equipo", nunca "Al iniciar sesión". Añadir un retraso de 30-60 segundos da margen a que los servicios de red y virtualización terminen de levantar antes de que se dispare la tarea.
- Acción: programa
C:\Windows\System32\wsl.exe, argumentos-d Debian(o--execpara lanzar un comando concreto sin abrir una shell interactiva).
En la pestaña de configuración conviene activar "Ejecutar la tarea lo antes posible si se pierde un inicio programado" y limitar los reintentos (por ejemplo, cada 5 minutos hasta 3 veces).
El punto débil: los reinicios en frío
En un apagado y arranque limpios, este esquema suele funcionar sin problemas. El punto donde falla con más frecuencia es tras un corte de energía o un reinicio en frío: en ese escenario, servicios como LxssManager o vmcompute pueden tardar más en estar operativos, y la tarea puede dispararse antes de que el subsistema esté realmente listo para aceptar la orden.
Por eso el retraso en el desencadenador y los reintentos no son opcionales: son la diferencia entre que el sistema se recupere solo o se quede en un estado a medias que solo se detecta al intentar usarlo.
Verificación real, no solo el historial de la tarea
El Programador de tareas puede marcar la ejecución como "correcta" simplemente porque wsl.exe devolvió un código de salida limpio, sin que eso garantice que la distribución sigue viva minutos después. La comprobación fiable pasa por reiniciar sin iniciar sesión con ningún usuario y, desde otra sesión (RDP o acceso local), ejecutar:
wsl -l -v
wsl -d Debian -- uptimeReforzar con una comprobación periódica
Si el objetivo final es que Debian esté disponible para recibir conexiones (SSH, rsync, un cron interno), es razonable no depender únicamente del arranque inicial. Una segunda tarea programada, ejecutada cada 5-10 minutos, que compruebe wsl -d Debian -- uptime y relance la distribución si falla, añade una capa de resiliencia frente a fallos puntuales del primer arranque.
