Con scripts de inicio (o con openrc) siempre podría ejecutar servicios desde una raíz de instalación diferente.
pero cuando corro chroot /somepath/to_root /usr/bin/systemctl start someservicetengo:

Running in chroot, ignoring request.

¿Hay alguna manera de forzar a systemd a ejecutar el servicio?

Actualización:
Olvidé decir que mi sistema host ejecuta scripts de inicio o openrc, pero nunca systemd, y que uso chroot para solucionar problemas de sistemas Unix que ni siquiera pueden iniciar un shell mínimo.

Un problema bien conocido en las distribuciones systemd (Arch Linux, OpenSUSE, Fedora).

Systemd reemplaza sysvinit y proporciona una gran ventaja sobre esto. En sysvinit, cuando solicita que se inicie un servicio, hereda el contexto de ejecución de la persona que invoca el script, que incluye variables de entorno, ulimits, etc. Por el contrario, Systemd mejora esto al notificar a un demonio, que comenzará el servicio en un entorno bien definido, saludable y constante, donde, por supuesto, el rendimiento de los servicios es mucho más fácil de predecir, ya que el entorno es siempre el mismo.

Esto implica que, cuando llamo systemctl desde dentro del chroot, es irrelevante que esté dentro de chroot, el entorno que se heredará sigue siendo el del PID 1, no el actual. Pero se pone peor que esto: dado que los enchufes de comunicación se colocan dentro / ejecutar / systemd, ¡un proceso en un chroot ni siquiera podrá hablar con el sistema init!

Entonces, ¿cómo se hace chroot'ing en las distribuciones systemd?

1. Si todo lo que quiere hacer es tener un contenedor de Linux, esta página de Arch Wiki le dirá cómo configurar un contenedor de Linux en menos de 30 segundos, gracias a systemd-nspawn.

2. Si, en cambio, realmente desea un entorno chroot, esta hermosa y clara página web le proporcionará dos soluciones de trabajo (la segunda es una versión modificada de la que se ofrece en el punto n. ° 1).

systemd solo ignora los "servicios", así que solo ejecuto los comandos daemon manualmente.

Entonces en lugar de

service sshd start

yo suelo

/usr/sbin/sshd -D &

Varios años más tarde debo admitir que solo hay una solución para la mayoría de los problemas prácticos de Systemd. Porque el error es Systemd mismo

Estoy realmente harto de Systemd ya que tuve problemas que nunca enfrenté con cosas como Upstart u Openrc:

• La aplicación de un núcleo que requiere soporte de cgroups (en lugar de hacerse opcional pero habilitado por defecto dentro de un archivo de configuración) incluso para sistemas integrados con solo 24Mb de ram y sin almacenamiento de escritura.
• A pesar de la afirmación de ser modular, en tiempo de ejecución, el infierno de la dependencia lo convierte en un fuerte objeto divino: ¿quiere arrancar sobre un solo reiser4 rootfs? No es posible porque muchos programas requieren systemd-udevdlo systemd-initque requiere el systemd-bootpaquete que no puede instalarse al mismo tiempo que grub2tampoco puede leer imágenes del núcleo de una partición reiser4.
• ¿Quieres conectarte a internet a través del acceso telefónico Bluetooth? Si no funciona con su teléfono Samsung java me, entonces no puede ejecutar los scripts y el software de línea de comando que anteriormente funcionaba manualmente networkd.
• Aunque reconozco que el mayor problema es si está construyendo y manteniendo su propia distribución de Linux: el módulo init de systemd en sí tiene tantas dependencias que no puede proponer elegir otro sistema init a través de diferentes paquetes de instalación.
• Buena suerte para ver los registros si no puede hacer chroot en su sistema o si actualizó desde libdb4.8 (mientras que al menos, en el peor de los casos, Microsoft tiene sus archivos de registro en formato xml) .

La única solución :

Systemd es un complejo poco práctico para resolver problemas: como alsa en lugar de ossv4. Entonces, si tiene algo que usa systemd, simplemente borre todos los datos:

dd if=/dev/urandom of=/dev/dm−0 bs=1M

e instale algo que no lo use en absoluto mientras resuelve problemas de SysV Init como Gentoo con Openrc.
En cuanto a mi pregunta, systemd crea cosas como el registro de Windows®: si una parte se arruina, entonces se acabó.

No. Los servicios son ejecutados por systemd (pid 1), no por systemctl directamente (que solo envía una solicitud de inicio), y dado que systemd se ejecuta fuera del chroot, también lo hará el servicio.

Aunque técnicamente podría ser posible implementar esto (haciendo que systemctl pase de alguna manera su raíz a systemd), es poco probable que suceda ya que ya existe una herramienta para crear contenedores completos ( systemd-nspawn /somepath/to_root). Sin embargo, siempre puedes contactar a la lista de correo .

Enfrenté este problema una vez que traté de abrir la red en modo de rescate usando la configuración de red desde chroot. Finalmente esto funciona para mí:

service --skip-redirect <service> restart

o:

SYSTEMCTL_SKIP_REDIRECT=_ /etc/init.d/<service> restart

Si está iniciando un servicio de estilo inetd con activación de socket, considere iniciar stunnel en su lugar con un archivo de configuración que especifique tanto un chroot como su binario como un objetivo de inicio de estilo inetd.

Tenga en cuenta que puede tener problemas con SELINUX. En un sistema Oracle Linux 7.1, tuve que "chcon -v --type = stunnel_etc_t" en todos los archivos que Stunnel necesitaba leer.

Deberá usar el cifrado TLS en el lado del cliente del zócalo (es decir, otro stunnel con "cliente = sí" en la configuración). Avísame si quieres más detalles sobre esto.

Puede usar el nohupcomando para iniciar servicios en chroot. Para iniciar el httpdservicio, por ejemplo, lo hago así.

nohup httpd /dev/null &

para detenerlo pkill httpd