Sid X.Org going crazy

A few apt-get update's ago, my X.Org server suddenly stopped working properly with my keyboard. Kb still worked fine in pure console, but when I typed anything in X my kb scroll lock led was turned on and off as I typed, making it impossible to write properly. Also, it was like the Ctrl key was costantly kept pushed.

The errors I got were only of this kind:
expected keysym, got ISO_Level5_Shift: line 17 of level5
expected keysym, got ISO_Level5_Shift: line 23 of level5
expected keysym, got ISO_Level5_Latch: line 27 of level5
expected keysym, got ISO_Level5_Latch: line 32 of level5
expected keysym, got ISO_Level5_Lock: line 36 of level5
expected keysym, got ISO_Level5_Lock: line 41 of level5
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning: Multiple interpretations of "NoSymbol+AnyOfOrNone(all)"
> Using last definition for duplicate fields
> Warning: Multiple interpretations of "NoSymbol+AnyOf(all)"
> Using last definition for duplicate fields
> Warning: Multiple interpretations of "NoSymbol+AnyOfOrNone(all)"
> Using last definition for duplicate fields
Errors from xkbcomp are not fatal to the X server
expected keysym, got ISO_Level5_Shift: line 17 of level5
expected keysym, got ISO_Level5_Shift: line 23 of level5
expected keysym, got ISO_Level5_Latch: line 27 of level5
expected keysym, got ISO_Level5_Latch: line 32 of level5
expected keysym, got ISO_Level5_Lock: line 36 of level5
expected keysym, got ISO_Level5_Lock: line 41 of level5
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning: Multiple interpretations of "NoSymbol+AnyOfOrNone(all)"
> Using last definition for duplicate fields
> Warning: Multiple interpretations of "NoSymbol+AnyOf(all)"
> Using last definition for duplicate fields
> Warning: Multiple interpretations of "NoSymbol+AnyOfOrNone(all)"
> Using last definition for duplicate fields
> Warning: Type "ONE_LEVEL" has 1 levels, but has 2 symbols
> Ignoring extra symbols
Errors from xkbcomp are not fatal to the X server

I finally got the situation manageable by configuring /etc/X11/xorg.conf this way:
Option "XkbRules" "walkaround"
#Option "XkbRules" "xorg"

Don't ask why, but now I can use my kb at 70%. I still get some errors, such as can't type letters with accents, @, £ and so on, plus, obviously, the following:
(EE) XKB: Couldn't open rules file /usr/share/X11/xkb/rules/xfree
(WW) Couldn't load XKB keymap, falling back to pre-XKB keymap
(EE) Error compiling keymap (server-0)
(EE) XKB: Couldn't compile keymap
SetClientVersion: 0 9
SetKbdSettings - type: 0 rate: 30 delay: 500 snumlk: 0

Finally, I found the bug filed on bdo:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514975

Following its instructions, I upgraded libx11-6 from 1.0.3-7 to 1.1.5-2 and restored Option "XkbRules" "xorg" in xorg.conf. After restarting X and issuing setxkbmap it I can finally use my kb 100%. Yikes!

How to enable a grayed out COM+ button on Win 2003

Case: on a Win 2003 server (not DC) it is impossible to enable COM+ because its button ("edit limits") is grayed out. How to enable it?

The referring security policy is: DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax, which can be found in: Local Security Settings\Security Settings\Local Policies\Security Options, and it must be set to "Not Defined" in order to have the button enabled.

On the (not DC) box, it seems to be impossible to set the policy to such value, and therefore the following registry key must be erased: HKLM\Software\Policies\Microsoft\Windows NT\DCOM.

Unvisible meta-LUN

I happened to see a Windows box not being able to see a meta-LUN (a bigger LUN formed of several "standard" size LUN) because its id was a too high number.
To keep in mind.

log4j causing OutOfMemory error

OutOfMemory Error on application server.

Thread dump analysis reported 15 threads active out of 650. The others were in wait. Inactive threads stack trace reported the following:

at java.lang.Thread.sleep(Native Method) at org.apache.log4j.helpers.FileWatchdog.run(FileWatchdog.java(Compiled Code))

In here http://www.theserverside.com/discussions/thread.tss?thread_id=27315 I found the following:

I found from the thread dump that lot of threads are created for log4j and not getting recycled.(see the thread dump below). I masked the log4j logging from my code. These log4j threads still get generated. Any ideas???

Thread Dump
"Thread-10" daemon prio=5 tid=0x113015d0 nid=0x838c waiting on monitor [0x133bf000..0x133bfdbc]
at java.lang.Thread.sleep(Native Method)
at org.apache.log4j.helpers.FileWatchdog.run(FileWatchdog.java:95)

SOLUTION [in short: log4j configureAndWatch() spreads lots of threads without deallocating them, eventually causing OOM exceptions]:

I have not worked on JBoss. I am having Weblogic Server. But I am pretty much sure that JBoss might let you do similar stuff.

1. After you have launched the server, run your application in a loop.
2. At the point where the server says that it cannot create new native threads, get a thread dump. In weblogic I did it by running the command :

java weblogic.Admin -url hostname:7001 -username admin -password mypassword THREAD_DUMP

3. Take a look at all the threads that are waiting on monitor. Chances are that 90% of the threads will be spawned by same process. In my case, it was

"Thread-14" daemon prio=5 tid=0x11999e90 nid=0x3388 waiting on monitor [0x135bf000..0x135bfdbc]
at java.lang.Thread.sleep(Native Method)
at org.apache.log4j.helpers.FileWatchdog.run(FileWatchdog.java:95)

I knew that this has something to do with log4j framework that I was using for logging.

4. So I started masking the logging lines, to see where this was being generated from. Eventually I found that the line
DOMConfigurator.configureAndWatch(fileFileName, logFileWatchTime)
was generating the threads that were not getting recycled. So I just went ahead and masked them.

Now everything works fine. It is going to be a different day I will be spending trouble shooting why this is happening. I was using this, because I liked the idea that by doing so, you could dynamically change log4j properties file and not restart the server.

But for now, I can leave with the idea of restarting the server if I change any configuration in log4j properties file. ;->

What i would suggest is that instead of looping 1000 times, just loop 20 times. Get a thread dump before you run your client and after you run youyr client. See what threads are created new, and if most of them are for same process, you need to see where they care created. It might be a bug in your code or third party library that you are using.

first post

First post!
Why a blog? To keep track of stuff I'd be forgetting after a few time.
Hopefully I'll keep it updated.