Write process pid file earlier

[bevacqua]

Should fix #4680. I presumed no tests should have to change but feel free to grunt at me if that's not the case.

[epixa]

I don't think it make sense to write a pid file if the process never binds to a port. It's possible at the moment to instantiate KbnServer to be used programmatically without ever having the intention of binding it to a port. In some of our tests for example, we're probably instantiating dozens of instances of KbnServer. I think we're also doing it in the cli plugin installer in order to run the optimizer.

[epixa]

@bevacqua What do you think?

[bevacqua]

What purpose does the pidfile serve? I feel like the pidfile is associated more with clustering than with listening. Workers may take a while to warm up before they become operational, but in the meantime not knowing the cluster's pid may be detrimental to things depending on that file to exist while the cluster is running.

That said I'm not familiar with the use cases nor with the clustering architecture used in Kibana.

[spalger]

I feel like the pid should be written as soon as we have it, and removed only when the process is actually shutdown. My opinion would be different if we were trying to provide an "operational kibana instance id", but I feel like this is more about knowing if the process is running, and how to address it (via signals, etc) if so.

Consider this scenaio:

start nginx
stop nginx #-> error: nginx isn't running
sleep 1
stop nginx #-> nginx stopped

[epixa]

I certainly think that's reasonable, I've just never heard of storing pid in a file when the process isn't intended to be long lived.

LGTM

[bevacqua]

@spalger Assigning you to take a second glance at this. Thanks!

[rashidkpc]

I don't see any issues with this, @spalger did you want to take another look at it?

[spalger]

LGTM