[DRE-maint] unicorn: native systemd service

[Dmitry Smirnov]

On Mon, 22 Jun 2015 19:45:23 Hleb Valoshka wrote:
> It seems that --update-rcd-params=disable (or remove) is the solution.

I tried that but it does not work and produces error on installation of the 
package...


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

Maybe we can recommend "needrestart" package (if it can take care of restart 
for us)? O, I've just learned that "transparent upgrade" should send a custom 
signal to "unicorn" process...


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

Right but at least we need to make sure that custom restart code is systemd-
aware...


> > 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'm not sure I understand "transparent upgrade". Is it zero downtime restart 
achieved by sending SIGUSR2 to the unicorn process and then sending QUIT 
signal again after delay? It should be safe to do so from postinst.

Looks like we need to follow "Procedure to replace a running unicorn 
executable" described here:

    http://unicorn.bogomips.org/SIGNALS.html

Besides old postinst was starting "unicorn" unconditionally and I'd like to 
avoid that.


> > 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?

Suppose you modified init.d script -- you will have to either create a new 
interface (e.g. non-standard "zero-restart" command) or to modify behaviour of 
"restart" which make the latter do unexpected things. Either way if you take 
care of init script it will not work for systemd users (and they are the 
majority).

Perhaps it will be best to introduce a new binary that user could run on 
upgrade to do "zero downtime restart" (we can run this utility from postinst).
What do you think?


> > 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.

It is our problem because like it or not Debian is now "married" to systemd.
Remember that it is not users' fault to use default init system so let's try 
to offer a solution for them.


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

Technically it is not a "knowledge" but an advisory info on desirable order of 
start to init system... Looks nice to me. :)

-- 
All the best,
 Dmitry Smirnov.

---

You have to start with the truth. The truth is the only way that we can
get anywhere. Because any decision-making that is based upon lies or
ignorance can't lead to a good conclusion.
        -- Julian Assange, 2010

-------------- 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/20150623/e5c65b68/attachment.sig>