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