[DRE-maint] unicorn: native systemd service

[Hleb Valoshka]

On 6/22/15, Dmitry Smirnov <onlyjob at debian.org> wrote:

> Perhaps it might be better to make sure that daemon is not enabled after
> first install of the package?

It sounds reasonably.

> I realised that "dh_installinit  --no-start" still enables automatic start
> of
> daemon so I've added workaround to "postinst" to disable daemon on first
> install.

It seems that --update-rcd-params=disable (or remove) is the solution.

> Also I dropped old service start/stop/restart code from {postinst|prerm} in
> favour of debhelper scripts. I believe custom code was redundant and not
> aware
> of systemd so IMHO it is the best to remove it. I understand this approach
> might be a bit intrusive so please revert if you prefer to keep old
> behaviour.

I don't want to lose transparent upgrade feature and it's not possible
with default code from dh_installinit.

And of course I don't want to lose features just because of systemd.

> I think that debhelper is already handles service restart gracefully so
> "transparent upgrade code" might be just redundant.

No. Transparent upgrades are supported only by nginx and unicorn
afaik, so I don't think that dh is aware of it. It can just restart
service.

> I believe it should not be in init.d script because init.d is better stay
> simple and don't do unexpected things.

No. How will you behave after security upgrade of ruby or redmine?
Restart unicorn dropping connections?

> Also I'd like to keep SysV and Systemd
> scripts close to each other so service restart would behave more or less
> similar disregarding of the init system.

If systemd does not allows custom actions it's systemd's problem.

>>  * "Should-Start: mysql" looks as dirty hack but it looks reasonable,
>
> It is not a "dirty hack". It is a legitimate SysV facility to advise on
> desirable order of start. See more in

I mean knowledge of existence of particular db.