Mozilla in recent releases is making it really hard for non-systemd distros to comply. Fake non-systemd distros using udev and elogind out of the latest systemd don’t seem to have a problem.…
One thing i can think of is that systemd won’t work in chroots(tell me if i’m wrong, help!). That is, apps requiring systemd cannot be run in chroot environment as it does not “boot up” at all. Systemd, due to it being an init system used to boot up, and being a daemon for other apps, makes it that you can’t run such apps in a non-booted environment.
I would like it so much if it was splitted into two something like “initd+systemd” or “systemd+servicesd” for boot up and running services seperately. So you can choose your init system or not to have an init system for chroot.
This looks like a replacement for chroot itself. It would be better if i can spawn a systemd process inside chroot that take care of services. And i can’t understand why it wants to stick into PID 1 of host even when running in chroot.
One thing i can think of is that systemd won’t work in chroots(tell me if i’m wrong, help!). That is, apps requiring systemd cannot be run in chroot environment as it does not “boot up” at all. Systemd, due to it being an init system used to boot up, and being a daemon for other apps, makes it that you can’t run such apps in a non-booted environment.
I would like it so much if it was splitted into two something like “initd+systemd” or “systemd+servicesd” for boot up and running services seperately. So you can choose your init system or not to have an init system for chroot.
At first sight, it looks like it can be used with chroots thanks to
systemd-nspawn(I haven’t tried it though)This looks like a replacement for chroot itself. It would be better if i can spawn a systemd process inside chroot that take care of services. And i can’t understand why it wants to stick into PID 1 of host even when running in chroot.