I can't login anymore to the server, neither via Remote Desktop nor ssh

2 weeks with no problems so far. 10.5.5 certainly seems to have helped for me.

Macyoshi, have you tried leaving a terminal window open and logged in as root(not exactly secure but..). When users can no-longer log in, try a killall DirectoryService and see if that fixes it? Atleast that will tell you if it is a DS problem.

This is happening because your system is creating lots of files in /var/db/dslocal/nodes/Default/config

It has created so many files that you are up to that very large number of 1's you see - you need to delete all of the ServicesInformationxxxxxx....x files (where the x's are numbers). Note you might have difficulty doing this due to the number of files involved, in which case probably the simplest thing to do is deleted them more selectively. (i.e. rm ServicesInformation11111*' etc.)

I was having this problem and also getting this:

Oct 17 11:09:49 starbuck servermgrd[51]: servermgr_web: Failed to find vhost for key 8FC1BCA0-B545-49F0-B031-5982EDEDC38A. Re-creating 'Default wild-card web site' siteID=*:80_

And our CPU utilisation was spiking like crazy causing system slow down.

Our web service was not running on our 10.5.5 server, but it was in the list of services in Server Manager. I've found that if I untick the web service from the list of managed services the problem goes away. (In fact I unticked all the services that we are not actually using).

Folks

It has been 2.5 weeks since I upgraded to 10.5.5 from 10.5.4 and the problem hasn't appeared again. I think it is soled in my case

Vince Dolan

I'm running 10.5.5 and still having this problem. Anyone else? Seems the 10.5.5 update didn't fix anything.

/var/db/dslocal/nodes/Default/config is jam-packed with ServicesInformation23486.plist like files.

Sample of the error /var/log/system

Oct 28 11:47:39 vp1095 Python[63868]: Record of type dsRecTypeStandard:Config named 'ServicesInformation44720' already exists in /Local/Default. Trying with new name: ServicesInformation44721
Oct 28 11:47:39 vp1095 servermgrd[21299]: Record of type dsRecTypeStandard:Config named 'ServicesInformation27355' already exists in /Local/Default. Trying with new name: ServicesInformation27356
Oct 28 11:47:39 vp1095 Python[63868]: Record of type dsRecTypeStandard:Config named 'ServicesInformation44721' already exists in /Local/Default. Trying with new name: ServicesInformation44722


Ta,
-AG

After upgrading to 10.5.5 we are still seeing the problem on 2 servers but it seems a lot less frequent now.

It doesn't happen on 4 other 10.5.5 servers we run. I can't see any differences in the set up of the good v bad ones. They were all set up by the same person following the standard company 'help sheet' we use.

I removed all ServiceInformation files from /var/db/dslocal/nodes/Default/config/ and did a reboot. The server is now running nice but AFP shares don't list, the WIKI doesn't start and iCal doesn't start now either "No virtual host found for iCal service".

But that's another problem...

-Andrew G

We have noticed that the number of times a server goes unresponsive seems to be tied to the amount we watch it with 'Server Admin'. Is this a classic case of "the observers influencing the outcome of an experiment"?

This last week or so we haven't opened 'Server Admin' for more than a quick check and all servers have stayed up.

Previously when we were experiencing problems either my colleague, me or even both of us, had 'Server Admin' open all the working day in the background watching them.

I wonder if anyone else here can try this or has noticed anything similar?

Nobody has commented on this possibility but to add further evidence to the theory...

We have been avoiding having 'Server Admin' open apart from a quick check daily check for the last few weeks. All 10.5 servers have stayed responsive. Then yesterday one of my colleagues accidentally left 'Server Admin' running on his Mac. One of the 10.5 servers then went unresponsive.

Coincidence?

I'm having this issue on 10.5.6
What happens is that you get tons of those files which fill the disk but the bigger problem is that your System.log gets filled up with error messages until the disk is 101% full. In my case this happens at 4.1GB of system.log.

Somebody on this list said he got away by disabling ssh. I will give this a try in another way. If your machine is exposed to the internet, it is happening very often that "hackers" or let's say "script kiddies" try to find open accounts like "john" with password "john". So they try thousands of possible usernames on your hosts. I see that every day on my linux machines. It might be that such an attack (even not successful) starts creating this issue. So disabling ssh on your firewall (if you dont need it, I do actually) or disabling the port for Remote Management could be the trick.

TO BE VERIFIED, just a wild idea which matches the pattern seen here.

Thought I'd share some success I had restoring a 10.5.6 server what was experiencing similar problems. System.log showed multiple types of errors:

WPWebServices createServicesInformationRecordInLocalNodeWithSession:: couldn't
create the Computer record in /Local/Default. Reason: (null)

WPSession createRecordWithType:attributes:inNode:error:: * Warning: the record of type dsRecTypeStandard:Config was created successfully, but OpenDirectoryFramework cannot find it. More info: recordName 'ServicesInformation' in /Local/Default

Record of type dsRecTypeStandard:Config named 'ServicesInformation8907' already exists in /Local/Default. Trying with new name: ServicesInformation8908

*Most critical was DirectoryService stealing 80-120% of the CPU.*

Essentially the system was having problems reading the original ServicesInformation.plist which lives in /var/db/dslocal/nodes/Default/config/ServicesInformation.plist

There were over 47000 ServicesInformation.plist files in the /var/db/dslocal/nodes/Default/config directory. I could safely remove them (leaving the original ServicesInformation.plist file) and they'd start being created again. I could read ServicesInformation.plist fine but opening in a Plist editor revealed it was a corrupt file.

I was able to rectify this by first creating a backup of the file, rebooting in single-user mode and deleting the original ServicesInformation.plist file. When the system booted, it created a new one. Voila like magic everything was fine.

Hope this helps someone