[DRE-maint] unicorn: native systemd service

[Dmitry Smirnov]

On Sun, 21 Jun 2015 18:19:44 Hleb Valoshka wrote:
> I hope it works properly (I can't test as I'm not a systemd
> user).

I've been using unicorn.service for some weeks and it works for me although my 
local .service file also creates directory for .sock file and set permissions 
on it...


> But I have several comments regarding your changes:
>  * You have removed "CONFIGURED" variable, that's not good because
> unicorn may be installed as a dependency for Rainbows (or any other
> unicorn-based server) and in this case it sh'ld not be started (of
> course user can disable it with update-rc.d but it's not a good idea).

As far as I understand current situation, .default file should not control 
activation of daemon because it is redundant (duplicates SysV functionality) 
and not standard among system daemons. Now when systemd is introduced, 
.default file have more potential to interfere and increase complexity.

I believe it will be better to manually activate service with "update-rc.d 
unicorn enable" when needed. This is also beneficial as it is makes init 
systems behaviour closer to each other.


> So I'll return it back.

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

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. On systemd side automatic enable of service is already prevented by 
"dh_systemd_enable --no-enable" override.

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 shall be happy to discuss more and answer your questions.


>  * I want to move transparent upgrade code from post-install hook to
> init-script because it may be useful not only on upgrade of unicorn
> package but with ruby and application upgrades as well. I hope
> "invoke-rc.d unicorn upgrade || invoke-rc.d unicorn restart" will be
> enough in case of systemd too.

I think that debhelper is already handles service restart gracefully so 
"transparent upgrade code" might be just redundant.
I believe it should not be in init.d script because init.d is better stay 
simple and don't do unexpected things. 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.


>  * "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 

    https://wiki.debian.org/LSBInitScripts

I think it makes sense because many Ruby apps depend on database while 
database do not depend on Ruby services. I've added this because I've seen 
failures when Unicorn start my Redmine before MySQL and Redmine at unicor fails 
to start on reboot of the server because database is not ready yet.


> I'll rather add postgres there too.

Good idea. :)


> Your other changes look reasonable, thanks.

Thank you, I'm glad to read that. :)


> > I shall be happy to answer all your questions and hopefully help little
> > more with Unicorn maintenance, if time allows.
> 
> Unicorn does not require a lot of maintenance efforts, but all that
> systemd stuff does.

Not really. It's just introduction of service is a bit tricky due to clashes 
with .default file but I think I've managed to solve that. We might also need 
a NEWS file to notify about changes...

-- 
All the best,
 Dmitry Smirnov.

---

What can be asserted without proof can be dismissed without proof.
        -- Christopher Hitchens, 2004
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-ruby-extras-maintainers/attachments/20150622/678669b5/attachment.sig>