> OpenAFS sees this problem about once a week. I keep meaning to just set up a cronjob to restart jetty.
Hmm.
I wonder if the problem isn't related to /tmp management.
Jetty unpacks the WAR file into a directory in /tmp. If some
cron script comes along once a week and deletes /tmp files that
have modification dates older than a week, that would kill Jetty.
And it wouldn't be Jetty's fault.
Hudson CI's embedded servlet container unpacks its WAR into ~/.hudson
because some systems have a /tmp cleaner that kills their WAR file
contents. I wonder if that's what we're really falling into here.
You could try adding -Djava.io.tmpdir=$HOME/.gerrit_tmp to your
Jetty Java arguments to force the Jetty process to place the unpacked
WAR elsewhere in the filesystem, out of reach of the /tmp killer.