Inicie un servicio systemd dentro de chroot


38

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.


1
También necesito ejecutar servicios en un chroot, siempre funcionó antes de openrc2, parece imposible ahora; (
neofutur

Estás tratando de resolver el problema equivocado. Si tiene OpenRC, debe convertir el servicio systemd en un servicio OpenRC. Realmente no hay forma de evitar eso.
Daniel B

@DanielB: ¡NO! ¿Alguna vez has oído hablar de systemrescuecd?
user2284570

No. Tampoco veo cómo se relaciona con tu pregunta.
Daniel B

Respuestas:


29

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).


He buscado systemd-nspawnpero no puedo ejecutarlo. Y no, esto no es para un contenedor, ya que el servicio debe ser utilizado por el host y la arquitectura de destino.
user2284570

2
Que nunca uso systemd en la raíz de mi sistema host. En mi caso no puedo mezclar systemd con openrc.
user2284570

1
@TwoD Eso no funcionará. La ejecución systemd-nspawnfalla con "No se ejecuta en un sistema systemd". a menos que el host también esté usando systemd.
hvd

1
@TwoD Y respondí porque no me parece para nada así. :) "No puedo ejecutarlo" es algo extraño que decir si tienes problemas para encontrar el ejecutable, por lo que sospecho que el problema es lo que puse en mi comentario: ejecutarlo muestra ese mensaje de error y no No hagas nada útil. Pero incluso si resulta que el problema realmente era dónde encontrarlo systemd-nspawn, señalar la nueva raíz no ayudará. O el host ya lo tiene (porque está ejecutando systemd), en cuyo caso se puede usar la versión del host, o el host no lo tiene, pero la nueva versión raíz no funcionará.
hvd

1
systemdse negará a ser ejecutadochroot
Erkin Alp Güney

4

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 &

Esto no funciona para todos los servicios. Algunos requieren ser iniciados como parte del iniciador de servicios del sistema como Xorg.
user2284570

startxtrabajará para Xorg.
Erkin Alp Güney

@ ErkinAlpGüney: no en chroot ... Debido a Dbus.
user2284570

4

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ó.


3
Reconozca que el diseño de algo realmente puede evitar obtener una respuesta para que la respuesta sea cambiar a algo que funcione . Y que esta es una respuesta real.
user2284570

1
Tenía la misma opinión, ahora tengo una visión un poco más equilibrada. Systemd tiene la gran ventaja de que realmente puede matar lo que debería matar . Es porque rastrea todos los subprocesos bifurcados con la función cgroup del kernel. Ninguna de las herramientas más antiguas puede hacer eso. Además, ¿recuerdas la basura de los scripts en /etc/init/*.sh?I también, pero hoy solo es un mal recuerdo para mí. Los archivos de servicio systemd son claros y tienen configuraciones de alrededor de 10 líneas . No 200 guiones largos de línea . Estas enormes ventajas tiene el systemd, estoy de acuerdo en que todas sus otras características son desventajas.
Peter dice reinstalar a Mónica el

Por cierto, voté su respuesta porque, además de sus ventajas, exactamente este tipo de críticas, exactamente en este tono, es lo que el desarrollo del sistema requiere para mejorar. Por ejemplo, acabo de intentar iniciar un postgresql en un chroot y tuve que desbaratar mi sistema raíz para hacerlo. Todavía hay muchas , muchas cosas malas, ¿verdad?
Peter dice reincorporar a Monica el

@peterh: desafortunadamente no todos lo comparten, quiero decir hasta el punto de eliminar la publicación. Esto no se trata de SysV init contra Systemd, sino más bien contra cosas como Openrc o incluso Upstart (que permite scripts de inicio cortos así como inicio de servicio paralelo). Al menos aprendí una cosa: Darwin es principalmente el ᴏꜱ de Apple ™ Windows es el ᴏꜱ de Microsoft y el diseño de Linux está dirigido principalmente por Red Hat. Aunque SysV init mientras es más lento no lo restringe a lo que puede hacer en tiempo de ejecución.
user2284570

Los scripts de servicios de @peterh también son muy claros cuando usa Openrc. El problema con cgroup en Systemd es que esta no es una opción que impide que Systemd ejecute cosas como Darwin o NetBSD.
user2284570

3

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 .


1
Bien, pero necesito usar systemctl ya que mi sistema host usa oepnrc. Quiero una solución totalmente independiente
user2284570

3
Enlodaré aún más las aguas diciendo: ¡Psst! Mencione RootDirectory=también, ya que está peligrosamente corto de votos a favor. (-:
JdeBP

@JdeBP: ¿Cuál es la diferencia (en términos de resultados) entre la variable RootDirectoryy el chrootcomando?
user2284570

@grawity: Entonces, ¿qué agregaría si pid 1es init?
user2284570

1

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

Agradable. Pero solo funciona con servicios heredados compatibles con Init (no funcionará para la creación de redes en el cuero crudo de Fedora) . Como dije en mi respuesta, la solución real es arruinar cualquier cosa que use systemd.
usuario2284570

0

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.


no, se trata de cosas como d-bus. Lo hago para diagnosticar problemas en el objetivo chroot.
user2284570

-1

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


¿Qué pasa con los servicios como Dbus que solo pueden iniciarse con el script systemd binario instalado?
user2284570

Puede iniciar dichos servicios desde su directorio con el comando de inicio.
ellooku

Que es un enlace simbólico contra systemctl. Entonces no funciona.
user2284570

Hago esto todo el tiempo en Fedora ejecutándose en mi Android. Puede ser que no sé cuál es tu problema.
ellooku

La consecuencia es este mensaje: Running in chroot, ignoring request.. No creo que lo hagas todo el tiempo aunque chroot. De hecho, el script de inicio requiere systemd.
user2284570
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.