Let mkcamp use start instead of restart

[racke]

This puzzled me - if you make a camp there won't be any server running. So IMHO it makes much more sense
to use "start" (first commit) which allows me to use more straightforward Nginx commandlines (no PID file
fiddling). The current variant is quite confusing.

Regards
Racke

[jonjensen]

Is there actually a problem for you with the current method? The reason it is like that is whenever a daemon (whether nginx, Apache, Interchange, or a database) gets stuck running, it hangs onto its TCP socket and you can't start a new one without stopping the old one. We find that restarting rather than just starting makes sure any dangling sockets are more likely to get shut down so the new daemon will work.

[racke]

Isn't the idea of camps to have distinct TCP port / sockets per camp? So I can't imagine a case where that socket is already in use. I ran into this when I used /usr/sbin/nginx -c __CAMP_PATH__/nginx/nginx.conf -s reload as httpd_restart.

[jonjensen]

Yes, distinct ports per camp, but any time you refresh an existing camp's database, restart its various services, etc., you have an opportunity for things to go awry. We have done dozens of camp systems and this happens often enough and trips up developers who don't have strong sysadmin skills.

[jonjensen]

You said: "I ran into this when I used /usr/sbin/nginx -c CAMP_PATH/nginx/nginx.conf -s reload as httpd_restart." But I don't understand yet what the problem is. Did it not work? Did nginx fail to start because it couldn't stop first?

[racke]

Pardon me, but mkcamp (setting up a camp) is something different than restarting services (that would be if camp is installed successfully). My first commit only changes mkcamp code.

The concrete problem with Nginx was that -s reload doesn't start when server isn't running.

[jonjensen]

Oh, ok. I didn't notice that. The same problem is there for mkcamp, though. It is still common that we have someone rmcamp and mkcamp --number=$n with the same camp number. If they didn't stop the old camp first, or some of the daemons were hanging, the new camp won't work. Restarting the way we do stop and then start takes care of that.

Could we cover both scenarios by first callling nginx stop before calling start here?

[racke]

Probably no point in arguing :-), but rmcamp should stop the daemons anyway.
Nginx stop + start could work yes.