From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8689 invoked from network); 28 Feb 2023 02:03:02 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 28 Feb 2023 02:03:02 -0000 Received: (qmail 15112 invoked by uid 89); 28 Feb 2023 02:03:26 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Received: (qmail 15105 invoked from network); 28 Feb 2023 02:03:26 -0000 From: "Laurent Bercot" To: "Oliver Schad" , supervision@list.skarnet.org Subject: Re: Systemd unit parser and s6 generator Date: Tue, 28 Feb 2023 02:02:59 +0000 Message-Id: In-Reply-To: <20230227172516.0d4bb760@flunder.oschad.de> References: <20230227172516.0d4bb760@flunder.oschad.de> Reply-To: "Laurent Bercot" User-Agent: eM_Client/9.2.1577.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable >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=20 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=20 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=20 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=20 weeds. -- Laurent