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 <charles_at_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 <
> istvan_at_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
>>
>> istvan_at_streambrightdata.com
>>
>
--
*Istvan Szukacs*
CTO
+31647081521 <//+31647081521>
+36 70 229 20 59 <http://+36702292059/>
istvan_at_streambrightdata.com
Received on Mon Jun 26 2017 - 15:05:15 UTC