Re: Survey answers part 3: systemd is not portable and what this means for our ports
Please don't CC me, I read the list.
Ondřej Surý <ondrej@sury.org> writes:
> On Mon, Jul 15, 2013 at 12:10 PM, Arto Jantunen <viiru@debian.org> wrote:
>> This has been discussed several times, there was even a GSoC project to
>> implement a systemd service -> init script converter (essentially
>> providing the same thing). Sadly this isn't even nearly as simple as it
>> sounds. The systemd service files are simple to write exactly since the
>> magic has been moved from them into the daemon, this converter or
>> wrapper needs to implement all of that for this to work.
>>
>
> I think this task is majestic only if you setup a goal of supporting every
> stanzas in systemd files.
>
> But If I look at .service files in my packages, I need to have support only
> for:
>
> ExecStartPre, ExecStart, PidFile and Reload
>
> The insserv headers might be written by hand.
In addition to that the wrapper also needs to be able to track the
processes started by the systemd service (the admin might want to stop
or restart services in addition to starting them), which systemd does by
using cgroups. Either you need the systemd unit files to have additional
info (how to make the daemon produce a pid file, or force it to never
fork, or what have you), or you need to implement reliable process
tracking without cgroups, at which point you have ported the essential
non-portable part of systemd.
Considering that we are still ignoring all of the difficult systemd
features (socket activation, network and fs restrictions, etc), it seems
to me that the wrapper isn't easy at all.
--
Arto Jantunen
Reply to: