Re: Systemd unit parser and s6 generator
what I can do, if it is of interest to you, is list all the directives in a service file and rate their conversion difficulty, so you can then evaluate your own service files and assess the feasability of an automated conversion tool. It took way longer than expected, and was a harrowing task, but it's finally done - and I'm glad I did it because it was a fascinating dive into the systemd worldview, and I'm all the more knowledgeable for it. (And a little dumber, too.) The results can be found here: https://skarnet.org/software/s6/unit-conversion.html I could probably have written a comment - and, sometimes, even an informative and non-snarky one! - for every single directive I listed, but I had to restrain myself in order to finish the document before the end of the year. Enjoy. -- Laurent
Re: Systemd unit parser and s6 generator
[...] We've discussed internally if we change that process and try to write a systemd unit parser, because all units are there in Ubuntu. If we could catch 90% of all cases, we need, we would be happy. If it would take 2 weeks of work, that would be fine. Did somebody of you try to implement something? What are your thoughts? So it seems that I am, years later, still the only person in the world to have done this (except not targetting skarnet toolsets). (-: As the voice of experience: Yes, you'll not get total coverage. You'll get "good enough for most cases", though I couldn't put an exact percentage on that. No, with the s6 tooling as it stands, you'll not be able to do everything. One of the things that one has to add is support for systemd's idiosyncratic non-UCSPI TCP/UDP service handling. Contrast the --systemd-compatibility flag to the tcp-socket-listen program in the nosh toolset to what s6-tcpserver4-socketbinder in s6-networking does. * https://jdebp.uk/Softwares/nosh/guide/commands/tcp-socket-listen.xml * https://skarnet.org/software/s6-networking/s6-tcpserver4-socketbinder.html That flag is used by convert-systemd-units to handle the conversion of socket units. * https://jdebp.uk/Softwares/nosh/guide/commands/convert-systemd-units.xml Most of the issues for s6 will be things like that, minor tweaks for (sometimes reasonable, sometimes downright absurd) systemd quirks and the odd missing tool. I wrote a set-control-group-knob command, for example, used by convert-systemd-units to translate the various unit file settings that end up twiddling knobs on control groups. I haven't seen a skarnet tool for doing that, yet; so that will be one necessary addition, for example. * https://jdebp.uk/Softwares/nosh/guide/commands/set-control-group-knob.xml s6-networking also does not appear to have UDP listening tools, which socket units for UDP sockets need. Timer units need tools like time-pause-until and time-env-add, similarly. Notice the --systemd-compatibility flag for that latter, too, and the notions like systemd month lengths. * https://jdebp.uk/Softwares/nosh/guide/commands/time-pause-until.xml * https://jdebp.uk/Softwares/nosh/guide/commands/time-env-add.xml There is, furthermore, a lot of stuff that you'll find that s6/nosh/&c. service run scripts do a lot better than systemd can. As you'll see from the convert-systemd-units(1) manual page, I added quite a number of things to the systemd unit file syntax for things that one can do in the aforementioned, such as UCSPI access control mechanisms (UCSPI being entirely alien to systemd) for starters.
Re: Systemd unit parser and s6 generator
We've discussed internally if we change that process and try to write a systemd unit parser, because all units are there in Ubuntu. If we could catch 90% of all cases, we need, we would be happy. If it would take 2 weeks of work, that would be fine. Did somebody of you try to implement something? What are your thoughts? Hi Oli, This is a subject that comes up regularly in the #s6 IRC channel. And I always answer something like this: The difficulty of converting systemd services to s6 services is not a syntax problem. The unit file syntax is mostly fine. The difficulty is the difference of world modelization between systemd and s6. systemd's view is very holistic, every component can depend on another one or rely on a systemd-only feature, and the unit file syntax reflects that; while s6's view is more local, every service is its own independent thing. But more importantly, the way systemd maps the system into concepts is pretty different from the way s6 maps the system into concepts, and these two views are not 1-to-1 compatible. Translating a setup between systemd and s6 requires intelligence; it is not possible to write an automated tool that does it accurately and idiomatically without going *deep* into things. In practice, yes, it is possible to write a converter that will take systemd.service files and turn them into s6 service directories, and that will work "most" of the time, depending on how your service files look. Most directives in systemd.service are directly translatable to s6 features. However, as soon as you start using esoteric systemd directives, the complexity explodes, and it's all a balancing act on what you want to support vs. how difficult it is. And only systemd.service files are automatically convertible; other unit files such as systemd.socket, systemd.path and systemd.target are all dependent on the systemd-centric system view and it is impossible to treat them without analyzing the entire system. I still owe you a couple hours of work, so what I can do, if it is of interest to you, is list all the directives in a service file and rate their conversion difficulty, so you can then evaluate your own service files and assess the feasability of an automated conversion tool. 90% coverage is doable if your services are super simple and don't rely on systemd-specific features, but it's very easy to get lost in the weeds. -- Laurent
Systemd unit parser and s6 generator
Hi everybody I don't know, if somebody has tried that ever. However we want to continue to use Ubuntu on s6 and packages today our s6 "units" manually. We've build a generator for that, that creates a base of service. But the call of this generator is once by a human being which manually decides which options make sense. Later he/she modifies maybe the generated result. We've discussed internally if we change that process and try to write a systemd unit parser, because all units are there in Ubuntu. If we could catch 90% of all cases, we need, we would be happy. If it would take 2 weeks of work, that would be fine. Did somebody of you try to implement something? What are your thoughts? Best Regards Oli -- Automatic-Server AG • Oliver Schad Geschäftsführer Hardstr. 46 9434 Au | Schweiz www.automatic-server.com | oliver.sc...@automatic-server.com Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47 pgpDMaY8GqTIY.pgp Description: OpenPGP digital signature
