[Pkg-systemd-maintainers] Proposed Release Goal: Add native systemd support to every packaging shipping a sysvinit script

[Michael Stapelberg]

Hi Bastian,

Bastian Blank <waldi at debian.org> writes:
> On Sat, Sep 21, 2013 at 07:50:22PM +0200, Michael Stapelberg wrote:
>> Bastian Blank <waldi at debian.org> writes:
>> > On Sat, Sep 21, 2013 at 06:45:41PM +0200, Michael Stapelberg wrote:
>> >> sysvinit scripts that many of our current packages provide. However,
>> >> when a package ships a native systemd service file in addition to the
>> >> sysvinit script, users enjoy a couple of advantages: they can now easily
>> >> enable/disable the service in a consistent manner using “systemctl
>> >> enable”, daemon output is stored in the journal by default, the process
>> >> tracking and related error reporting works better and users can use
>> >> drop-in snippets to tweak service behavior (e.g. resource limits).
>> >
>> > Can you please explain what does not work if the sysv compatibility is
>> > used?  systemd internally defines a complete service definition for each
>> > enabled sysv init script.
>> I didn’t say that things _dont_ work at all, I am saying that a few
>> details work better when providing a service file:
>
> By describing what works now you implied that it did not work before.
> Please update the proposal text to only list new supported stuff.
Due to the point discussed below, I have updated the proposal to clarify
the drop-in snippets part:
https://wiki.debian.org/ReleaseGoals/systemd?action=recall&rev=2

Thanks for your attention to detail.

>> • The drop-in snippets I mentioned above (i.e. files like
>>   /etc/systemd/system/apache2.service.d/more-memory.conf) only work with
>>   native service files AFAIK,
>
> Can you please actually test this?
I tested this and it actually works with sysvinit scripts. The second
point which you dropped in your citation still stands, though:

> and sometimes outright don’t make sense with a sysvinit script. As an
> example, you cannot reasonably specify a different ExecStart= line
> with custom arguments, because the ExecStart= line of a sysvinit unit
> contains /etc/init.d/service start

I have also appended another example to the wiki page: “Furthermore,
limits that you set with systemd might be overwritten in the init script
itself, rendering them useless.”

-- 
Best regards,
Michael