I was troubleshooting some problems with one of our laptops when I ran across a particularly disconcerting source: access to some registry entries by the administrator was no longer allowed. How this happened I can't even begin to imagine, but it doesn't appear to be an entirely uncommon occurrence. I found a nice, quick write-up on how to reset the permissions on the entire registry. A bit of a sledgehammer approach, but I think in this instance it was probably necessary.
So far things seem to be functioning normally again. Hopefully this will address the problems I've been seeing.
Tuesday, May 22, 2007
Monday, May 21, 2007
SUSE 10 System Time Drifting
The system time on our SUSE 10 box drifts rather horrendously. The main culprit appears to be the fact that it's running in a virtual environment. A quick search on Google indicates that this is not an uncommon problem, the source of which appears to be that SUSE 10 (linux kernel 2.6) uses an interrupt rate that is higher than the default host maximum (1000Hz vs. 100Hz).
See Clock in a Linux Guest Runs More Slowly or Quickly Than Real Time for more information.
I attempted to use the boot loader fixes suggested for the guest OS but did not have any luck. Even with the drift, the NTP daemon should be able to keep the time acceptably. Unfortunately it doesn't seem to work consistently. I suspect this may be due to the drift resulting in the system unable to verify the time. At any rate, I seem to have hit a wall in this regard.
Perhaps the best option for addressing this issue is with the setup of the VMX. One of the options within the environment is to sync the clock with the host operating system (
This last option is probably best because it negates the need for NTP on the guest OS, decreasing overall traffic to/from the server.
It looks like I'll be disabling NTP for the time being since it doesn't seem to be keeping time and it may possibly be crashing the server (too bad we can't just change the battery). And if we implement the preferred solution I won't need to re-enable it.
References:
See Clock in a Linux Guest Runs More Slowly or Quickly Than Real Time for more information.
I attempted to use the boot loader fixes suggested for the guest OS but did not have any luck. Even with the drift, the NTP daemon should be able to keep the time acceptably. Unfortunately it doesn't seem to work consistently. I suspect this may be due to the drift resulting in the system unable to verify the time. At any rate, I seem to have hit a wall in this regard.
Perhaps the best option for addressing this issue is with the setup of the VMX. One of the options within the environment is to sync the clock with the host operating system (
tools.syncTime = TRUE
). This option requires that the vmware-tools be installed correctly. Since we don't have access to the VMX parameters we'll have to work with tech services to see if this is set. (And if so why it isn't keeping the clock in sync.)This last option is probably best because it negates the need for NTP on the guest OS, decreasing overall traffic to/from the server.
It looks like I'll be disabling NTP for the time being since it doesn't seem to be keeping time and it may possibly be crashing the server (too bad we can't just change the battery). And if we implement the preferred solution I won't need to re-enable it.
References:
- SUSE Linux unofficial FAQ: Clock adjusting in SuSE Linux micro-howto
- The Unix Forums: Linux System with Strange IRQ Error
- VMWare Discussion Forums: Slow Linux 2.6 guests - clock looses 10 secs pr. 20 secs...
- MSMVPS.com: Clock in a Linux Guest Runs More Slowly or Quickly Than Real Time...
- VMWare KB: Clock in a Linux Guest Runs More Slowly or Quickly Than Real Time
Monday, May 14, 2007
Dreamweaver Find/Replace Funkiness
When using Dreamweaver 8.0.2 to do a find/replace occasionally the following message may be encountered:
References:
The following files changed after the initial search was performed:It appears to be a minor bug in DW. If you restart the program the same exact find/replace will work fine.
[current document]
References:
Monday, May 07, 2007
Webtrends crashing
I've run into yet more instances of WebTrends crashing while reading the web server logs. However, I've found that if you have FastTrends turned on the log parser will crash when reading the bad lines, but the next time you run the analysis the bad lines will be skipped. It may take more than one pass to get past the lines causing WebTrends problems, but otherwise the analysis seems to work just fine.
Subscribe to:
Posts (Atom)