Odi's astoundingly incomplete notes
New Entries
Petition to Oracle: Stop bundling Ask Toolbar with the Java installer
iptables connection tracking helpers
When your kernel tells you this:
It really urges you to include this in your iptables configuration:
IP_NF_RAW
IP6_NF_RAW
NETFILTER_XT_TARGET_CT
kernel: nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead. It really urges you to include this in your iptables configuration:
*raw :PREROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] [0:0] -A PREROUTING -p tcp --dport 21 -j CT --helper ftp [0:0] -A PREROUTING -p tcp --dport 6667 -j CT --helper irc [0:0] -A PREROUTING -p tcp --dport 6566 -j CT --helper sane COMMITRequired kernel config:
IP_NF_RAW
IP6_NF_RAW
NETFILTER_XT_TARGET_CT
kernel: Package power limit notification
I get this frequently in syslog:
These messages are logged by the kernel, in the file:
This feature is enabled by the X86_MCE_INTEL config option, which is located under:
So the kernel now gets thermal interrupts from your CPU when certain temperature limits are crossed. The kernel's thermal and power management then decides what to do to decrease the temperature. This is normal operation and nothing to worry about.
Dec 28 11:44:00 kernel: CPU0: Package power limit notification (total events = 355) Dec 28 11:44:00 kernel: CPU2: Package power limit notification (total events = 355) Dec 28 11:44:00 kernel: CPU1: Package power limit notification (total events = 355) Dec 28 11:44:00 kernel: CPU3: Package power limit notification (total events = 355) Dec 28 11:44:00 kernel: CPU1: Package power limit normal Dec 28 11:44:00 kernel: CPU0: Package power limit normal Dec 28 11:44:00 kernel: CPU2: Package power limit normal Dec 28 11:44:00 kernel: CPU3: Package power limit normalUsually when Firefox uses a lot of CPU. There are many forum posts regarding these messages. But there is nothing to worry about. A bit of background.
These messages are logged by the kernel, in the file:
arch/x86/kernel/cpu/mcheck/therm_throt.cThis feature is enabled by the X86_MCE_INTEL config option, which is located under:
Processor type and features [*] Machine Check / overheating reporting [*] Intel MCE featuresIn dmesg it shows this message, during boot, if the kernel decided to handle thermal interrupts (and not the BIOS):
CPU0: Thermal monitoring enabled (TM1)So the kernel now gets thermal interrupts from your CPU when certain temperature limits are crossed. The kernel's thermal and power management then decides what to do to decrease the temperature. This is normal operation and nothing to worry about.
iptables format changes
Gentoo has stabilized iptables 1.4.16. With that some changes to your iptables config are necessary.
Use conntrack instead of state module
before: -m state --state NEW
after: -m conntrack --ctstate NEW
Remove --reap from recent module
before: -m recent --update --seconds 30 --reap -j DROP
after: -m recent --update --seconds 30 -j DROP
Maybe there is more, but I haven't discovered it yet...
Use conntrack instead of state module
before: -m state --state NEW
after: -m conntrack --ctstate NEW
Remove --reap from recent module
before: -m recent --update --seconds 30 --reap -j DROP
after: -m recent --update --seconds 30 -j DROP
Maybe there is more, but I haven't discovered it yet...
Is kwin with GLES ready for desktops?
Martin Grässlin mentioned last summer that "4.8 we will be able to offer and default to OpenGL ES 2.0 for most of our users". Given the substantial time since that announcement, I wanted to try that with KDE 4.9.3 which was just stabilized in Gentoo today. I tested it on my iMac. Easy enough in Gentoo: enable the
The result was not too good unfortunately. I quickly realized that all menus were unusable because they either didn't show up at all, or faded in only halfway. Plus there was massive screen corruption when draging windows around on the desktop.
Same on the Zenbook with Intel SandyBridge and xf86-video-intel-2.20.14.
gles, gles1, gles2 USE flags and disable opengl for kde-base/kwin. Then recompile Mesa and kwin. Mesa version is 9.0 and xf86-video-ati is at 7.0.0, all on top of a 3.6 kernel.The result was not too good unfortunately. I quickly realized that all menus were unusable because they either didn't show up at all, or faded in only halfway. Plus there was massive screen corruption when draging windows around on the desktop.
Same on the Zenbook with Intel SandyBridge and xf86-video-intel-2.20.14.
Tuning mod_proxy and Jetty
Running a classic setup with Apache as a reverse proxy in front of a Jetty server, I ran into a problem. Apparantly most HTTP threads of Jetty were blocked for long period of times in the following stack within the AJP connector, and no threads were available for the HTTP connector:
Test Setup
To find the configuration problem I ran some tests on a local machine:
Jetty 7.4.3 config:
ProxyPass / ajp://localhost:8009/ min=1 ttl=20 acquire=10000 timeout=60
mod_proxy_http
ProxyPass / http://localhost:8080/ min=1 ttl=20 acquire=10000 timeout=60
JBoss
For comparison I ran the same test against an old JBoss 4.0.4 which uses Tomcat 5.5.
mod_proxy_ajp
ProxyPass / ajp://localhost:8009/ min=1 ttl=20 acquire=10000 timeout=60
mod_proxy_http
ProxyPass / http://localhost:8080/ min=1 ttl=20 acquire=10000 timeout=60
Conclusions
There is no benefit of using AJP instead of HTTP, the opposite is true. AJP really hurts. I have observed client timeouts only with AJP, never with HTTP. HTTP also was always faster then AJP. The AJP issues are mostly due to a bad implementation in Jetty as (JBoss') Tomcat seems to behave a bit better. But probably mod_proxy_ajp is to blame too, it seems to do something stupid with multiplexing the Apache threads to the AJP backend pool.
This test reveals striking differences between AJP and HTTP and how they behave with connection pools:
You can not mix HTTP and AJP connectors on the same Apache instance. Because there is no configuration that will work for both. Given the AJP numbers are so much worse than HTTP, and the behaviour with pools is so anti-intuitive, I recommend not to use mod_proxy_ajp at all.
It is advisable to disable keep-alive in scenarios with OTA connections. You can use mod_headers:
java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at org.eclipse.jetty.io.ByteArrayBuffer.readFrom(ByteArrayBuffer.java:388) at org.eclipse.jetty.io.bio.StreamEndPoint.fill(StreamEndPoint.java:132) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.fill(SocketConnector.java:209) at org.eclipse.jetty.ajp.Ajp13Parser.fill(Ajp13Parser.java:203) at org.eclipse.jetty.ajp.Ajp13Parser.parseNext(Ajp13Parser.java:265) at org.eclipse.jetty.ajp.Ajp13Parser.parseAvailable(Ajp13Parser.java:150) at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:241) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:529) at java.lang.Thread.run(Thread.java:662)The setup is:
- have many Apache threads
- Apache serves some static content and downloads
- Jetty serves the dynamic content
- Jetty has a limited thread pool to accomodate the max allowable load
- the clients are all application clients (not web browsers typically)
- the clients are mostly mobile with more or less shaky over the air connectivity (lots of timeouts, broken connections)
Test Setup
To find the configuration problem I ran some tests on a local machine:
- 100 clients making a simple dynamic request in parallel
- measure the time to complete all requests
Jetty 7.4.3 config:
- QueuedThreadPool.maxThreads = 30
- SelectChannelConnector.maxIdleTime = 300000
- Ajp13SocketConnector.maxIdleTime = 60000
- Apache 2.2.23
- mod_proxy_http
- mod_proxy_ajp
- differen values for MaxClients
ProxyPass / ajp://localhost:8009/ min=1 ttl=20 acquire=10000 timeout=60
| MaxClients | keep-alive | Time [s] | timeouts? |
|---|---|---|---|
| 150 | no | 60.1 | yes |
| 30 | no | 11.4 | no |
| 150 | yes | 74.7 | yes |
| 30 | yes | 70.3 | yes |
mod_proxy_http
ProxyPass / http://localhost:8080/ min=1 ttl=20 acquire=10000 timeout=60
| MaxClients | keep-alive | Time [s] | timeouts? |
|---|---|---|---|
| 150 | no | 2.0 | no |
| 30 | no | 6.0 | no |
| 150 | yes | 19.8 | no |
| 30 | yes | 66.0 | no |
JBoss
For comparison I ran the same test against an old JBoss 4.0.4 which uses Tomcat 5.5.
mod_proxy_ajp
ProxyPass / ajp://localhost:8009/ min=1 ttl=20 acquire=10000 timeout=60
| MaxClients | keep-alive | Time [s] | timeouts? |
|---|---|---|---|
| 150 | no | 14.5 | no |
| 30 | no | 9.4 | no |
| 150 | yes | 33.8 | no |
| 30 | yes | 68.5 | no |
mod_proxy_http
ProxyPass / http://localhost:8080/ min=1 ttl=20 acquire=10000 timeout=60
| MaxClients | keep-alive | Time [s] | timeouts? |
|---|---|---|---|
| 150 | no | 2.0 | no |
| 30 | no | 6.0 | no |
| 150 | yes | 21.6 | no |
| 30 | yes | 66.0 | no |
Conclusions
There is no benefit of using AJP instead of HTTP, the opposite is true. AJP really hurts. I have observed client timeouts only with AJP, never with HTTP. HTTP also was always faster then AJP. The AJP issues are mostly due to a bad implementation in Jetty as (JBoss') Tomcat seems to behave a bit better. But probably mod_proxy_ajp is to blame too, it seems to do something stupid with multiplexing the Apache threads to the AJP backend pool.
This test reveals striking differences between AJP and HTTP and how they behave with connection pools:
- mod_proxy_ajp only works well if the Apache and Jetty connection pools have the same size. A larger the difference make the performance worse.
- mod_proxy_http works better the larger the Apache connection pool is.
You can not mix HTTP and AJP connectors on the same Apache instance. Because there is no configuration that will work for both. Given the AJP numbers are so much worse than HTTP, and the behaviour with pools is so anti-intuitive, I recommend not to use mod_proxy_ajp at all.
It is advisable to disable keep-alive in scenarios with OTA connections. You can use mod_headers:
RequestHeader set Connection "close"
Graphics board thermal death anatomy
The Radeon board of my old MacBook Pro is dying. During an update the laptop may have overheated. Suddenly the screen got garbled. From now on every few boots only end in a kernel panic (segfault). Compositing refuses to use OpenGL and falls back to using XRender. Also the mouse cursor now has stripes filling the normally empty area of the cursor sprite (see image). The kernel log contains the following messages:[drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD) [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).OS-X doesn't want to boot any more. It gets stuck on an empty blue screen. Booting it in safe mode (holding down the shift key) or in single-user mode (holding command-S) works, though. Also there the cursor has the same stripy pattern.
Refit still boots and is usable, although I only get a black screen when it initializes the graphics card in "BIOS mode" most of the time. So I can control Grub only blindly, and I get no early boot messages from the kernel until the KMS driver loads.
Neat workaround for the funny barcode cursor: use the SWCursor option of the radeon driver.
Update: After a few months it got worse. With the radeon driver a lot of horizontal stripes and totally unstable. The machine would hang ever so often. Falling back to the xf86-video-modesetting driver works fine. I still get a stripy mouse cursor but at least it's stable.
Seems it's time to replace this old buddy with a new one soon.
All the best! Looking forward to a new Linux Install guide on the latest Macbook Pro.
- KSS
- KSS
JAX-WS wildcard address
If you have wondered how to make a JAX-WS endpoint listen on the wildcard address:
Endpoint.publish("http://0:8080/MyService", new MyService());
Just use 0 as the IP. If you wonder why that works, look at the implementation of Inet4Address.isAnyLocalAddress() which basically checks for zero.hostapd on Gentoo
When using hostapd on Gentoo, make sure to add the
debug USE flag. Otherwise you will never get any error messages from it. It will only exit with error code 1 and no message even if it's just a silly typo in the config file. Also no logging will work without that USE flag.Thank god I found this! Would have searched ages for finding this myself. +debug should be default for hostapd, I think I'll write a bug-report for this one.
Orecchiette cime di rapa
This is my version of pasta with Cime di Rapa. Cime di Rapa is an exquisite vegetable with a strong and slightly bitter taste. It's popular mostly in southern Europe and nearly unknown north of the alps. In Zurich you can find it throughout the winter season in smaller shops or on the market, very rarely in supermarkets.
This is a cheap and simple vegan/vegetarian pasta dish that's quickly prepared and tastes great.
You need:
Wash the Cime and chop it. We use the whole plant. Chop the parsley, garlic and onions. Setup the water for the pasta.
In a large pan, heat some olive oil and fry parsley, garlic and onions. I use enough oil so that they are actually fried and not roasted. So the onions do not get brown.
Add the chopped Cime di Rapa and after a minute add some water and/or red wine. Cover with a lid. The Cime should now cook in steam, it should not be roasted.
When the Cime gets soft, add the tomatos, purée and a tea spoon of sambal. Add a bit of water when the sauce gets too thick. Salt to taste. By this time the water should be boiling and you can put in the pasta and salt. When the pasta is ready, so is the sauce. Serve hot.
This is a cheap and simple vegan/vegetarian pasta dish that's quickly prepared and tastes great.
You need:
- fresh Cime di rapa (1 medium sized plant per person)
- Orecchiette
- Olive Oil
- Garlic (1 clove per person)
- Onions
- Tomatos in juice from the tin (200g per person)
- Tomato purée
- Sambal Oelek
- Parsley (fresh or from stock in your freezer)
Wash the Cime and chop it. We use the whole plant. Chop the parsley, garlic and onions. Setup the water for the pasta.
In a large pan, heat some olive oil and fry parsley, garlic and onions. I use enough oil so that they are actually fried and not roasted. So the onions do not get brown.
Add the chopped Cime di Rapa and after a minute add some water and/or red wine. Cover with a lid. The Cime should now cook in steam, it should not be roasted.
When the Cime gets soft, add the tomatos, purée and a tea spoon of sambal. Add a bit of water when the sauce gets too thick. Salt to taste. By this time the water should be boiling and you can put in the pasta and salt. When the pasta is ready, so is the sauce. Serve hot.