Could you be more clear about what you mean by "make systemd compatible"?
Do you mean loading systemd configuration files into s6, or the reverse?
The former strikes me as exceedingly difficult to implement in a complete
and correct manner.

One of the things that makes systemd so... controversial... is the amount
of complexity it pulls into what (in many folks' view) ought to be designed
as a simple subsystem (in the "simple enough that an implementation can be
obviously correct" sense). Because of that amount of complexity -- one
could rather easily implement a simple subset of its functionality, but
reaching full parity (and *maintaining* that parity as it continues to
grow, expand, and cross what would historically be distinct subsystem
boundaries) strikes me as a very ambitious project.

As a few examples of things that systemd provides that would need to be

- A mechanism based on UNIX domain sockets for implementing a watchdog, and
for processing file descriptors between subsequent invocations of the same
- Sandboxing of allowed syscalls (using a Linux-only mechanism not
applicable to other platforms s6 supports)
- Management of process-local filesystem, PID, and user namespaces (again,
using a Linux-only mechanism)
- Integration with a (again, linux-only and glibc-only) nsswitch module to
generate dynamic, transient user accounts local to an individual instance
of a process
- Integration with the linux-only cgroups mechanism for managing CPU,
memory, and I/O throughput limits

...and so on, and so forth. Consequently, any effort would necessarily be a
small subset, and plagued by compatibility issues whenever a distributed
.service file attempts to use functionality that a different process
supervision system couldn't implement without compromising portability (or
changing its behavior between platforms).

On Mon, Jun 26, 2017 at 9:02 AM Istvan Szukacs <>

> Hi,
> I have a crazy question about s6. Would it be possible to make systemd
> compatible? This question might sound stupid at first but here is the
> reasoning:
> - we have services with systemd service files already
> (/etc/systemd/system/*.service, etc.)
> - the previous alternatives all failed to gain traction because there was
> too much effort to change systems around to use them (
> and the linux platform
> is
> very fragmented
> - there is already too much effort went into systemd that would be hard to
> duplicate
> Questions:
> - is there anybody interested in such project?
> - is this feasible to do?
> Let me know what you think.
> Thanks in advance,
> Istvan
> --
> *Istvan Szukacs*

Reply via email to