Open Stack

On 12/16/2014 11:59 AM, Alan Pevec wrote:
> There's one issue with Type=notify that Dan Prince discovered and
> where Type=simple works better for his use-case:
> if service startup takes more than DefaultTimeoutStartSec (90s by
> default) and systemd does not get notification from the service, it
> will consider it failed and try to restart it if Restart is defined in
> the service unit file.
> I tried to fix that by disabling timeout (example in Nova package
> https://review.gerrithub.io/13054 ) but then systemctl start blocks
> until notification is received.
> Copying Dan's review comment: "This still isn't quite right. It is
> better in that the systemctl doesn't think the service fails... rather
> it just seems to hang indefinately on 'systemctl start
> openstack-nova-compute', as in I never get my terminal back.
> My test case is:
> 1) Stop Nova compute. 2) Stop RabbitMQ. 3) Try to start Nova compute
> via systemctl.
> Could the RabbitMQ retry loop be preventing the notification?
> "
> 
> Current implementation in oslo service sends notification only just
> before entering the wait loop, because at that point all
> initialization should be done and service ready to serve. Does anyone
> have a suggestion for the better place where to notify service
> readiness?
> Or should just Dan's test-case step 3) be modified as:
> 3) Start Nova compute via systemctl start ... &  (i.e. in the background) ?
> 
> 
> Cheers,
> Alan

What you describe above looks like a defect in the implementation. Of
course, waiting for more than 90s should be considered as failed, and I
wouldn't want in any case to have this timeout increased. Failed
attempts to connect to Rabbit shouldn't, IMO, be the cause for not
sending the notify signal.

Cheers,

Thomas Goirand (zigo)