Hi Charles, Yeah I can clarify. The only thing that I (or for that matter saner systems engineers) want from systemd is to be a better sysv init. I do not want logging, ntp and all the other crap that got sucked into it. I understand that service files are much better that shell scripts and this is a good argument but it does not justify the idiocracy that systemd became in the recent years. Ideally we could have a service (like s6) that does only that keeping the best parts of systemd as well. This would allow me to run redhat/centos based systems and use service files without being worried that a huge amount of CPU cycles going to a service that sole purpose is to keep services up that actually provide the functionality that I need. Does this clarify?
I see your point about the linux only things though. I am not sure what is the right approach there. I should dig deeper into Amazon Linux and see how they escaped systemd-hell. I. On Mon, Jun 26, 2017 at 4:47 PM, Charles Duffy <char...@dyfis.net> wrote: > 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 > reimplemented: > > - A mechanism based on UNIX domain sockets for implementing a watchdog, > and for processing file descriptors between subsequent invocations of the > same service. > - 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 < > ist...@streambrightdata.com> wrote: > >> 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 ( >> https://www.tecmint.com/best-linux-init-systems/) 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* >> CTO >> >> ist...@streambrightdata.com >> > -- *Istvan Szukacs* CTO +31647081521 <//+31647081521> +36 70 229 20 59 <http://+36702292059/> ist...@streambrightdata.com