How to delete unix socket entries
Paul Robinson
paul at iconoplex.co.uk
Wed Jun 25 04:51:52 PDT 2003
On Wed, Jun 25, 2003 at 03:15:17PM +0400, Varshavchick Alexander wrote:
> Paul, let me disagree with you about the attitude towards rebooting server
> as means of curing anything wrong there and "returning your machine to a
> known state". First of all, this is a production server and downtimes are
> less than desirable there. And the principal part of it, the _GOOD_
> operational system is always (or anyways must be) in a "known state" using
> your terms, and surely FreeBSD can be considered to belong to them.
> Rebooting a server to make it work gets M$ Windows to mind...
Couldn't disagree with you more in general terms. Somebody else here (or on
-chat) once said something like "The fact that a server can stay up for 300
days is a testimony to how good FreeBSD is. Unfortunately, it's also
testimony to how bad FreeBSD Systems administrators are".
If you have a production system designed so that can't take one box out for
120 seconds a week, your production system is wrong. You either need close
to something like 99.999% uptime, in which case you should be load-balancing
and/or clustering anyway, or you don't understand the problem.
Patching your src tree, re-building and YES! Shock, horror! RE-BOOTING on a
regular basis is something a competent sysadmin is not scared to do. In
fact, not doing it just accepts that you don't care about the health and
security of your systems. You are prepared to let security holes seep in,
stale libraries clog up disk space, your machine gracefully degrades into a
horrible, horrible state.
When I walk on site, if the sysadmin has a machine with an uptime over 150
days and is proud of it, I know I'm going to have an uphill struggle to beat
a clue into their thick, stupid, ignorant heads.
This is not about competing with MS. It's about running a secure, stable
environment. In your particular case, your environment isn't stable because
you have a server application that is core-dumping regularly. In that
eventuality (and seeing as you haven't given us a piece of code that
replicates the error) you have two choices:
1. Fix your broken server application
2. Reboot your machine on a regular
This is the only way you will ever have your server in a continual known
state and operate productionally in the manner you want. If you cvsup
-STABLE and rebuild the world before a reboot, you also get the benefit of
performance security patches. This is a Good Thing.
--
Paul Robinson
More information about the freebsd-hackers
mailing list