Dariush Debian Diary

417 - Expectation Failed Fix with 1.4.29 and:

server.reject-expect-100-with-417       =       "disable"

SEVERE: Catalina.start:
LifecycleException:  service.getName(): "Catalina";  Protocol handler start failed: java.lang.Exception: Socket bind failed: [22] Invalid argument
        at org.apache.catalina.connector.Connector.start(Connector.java:1097)
        at org.apache.catalina.core.StandardService.start(StandardService.java:457)
        at org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
        at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)

try:

apt-get remove libapr1

Debian - runsv after upgrade changes SVDIR to /etc/service from /var/service, which results in:

# sv -v d dsnscan4
fail: dsnscan4: runsv not running

to fix - stop all runing sv's:

# SVDIR=/var/service sv -v d dsnscan4
ok: down: dsnscan4: 1s, normally up

# SVDIR=/var/service sv -v d prom
ok: down: prom: 1s, normally up

and kill old runsv:

killall runsv-dir
killall runsv

and start new runsv ( all services will be up, because those 'sv d $service' are stored in different dir )

.subversion/servers: [groups] yourdomain = *.yourdomain.pl [yourdomain] http-auth-types = Negotiate

supposedly BIOS 1.08 fixes RAM problem, but in 1.09 the problem exists, that even though there is >4G ram in machine, OS can see only 3.2G. (lshw reports correctly installed memory though). Problem can be solved by downgrading to 1.08 or upgrading to 1.14. (1.10 supossedly is not enough)

"Negative cache rejected lookup for" on MacOSX (Snow Leopard), fixed by restart

(This happened after changing kernel from the one that saw raid members as /dev/sdb5 and /dev/sdc5, to one that saw it as /dev/sda5 and /dev/sdb5.)

Personalities : [raid1]
md1 : active(auto-read-only) raid1 sdb5[1] sda5[0]
      234372160 blocks [2/2] [UU]
     resync = PENDING

it will stay PENDING until the end of time, or until you do:

mdadm --readwrite /dev/md1

then it starts syncing:

cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sdb5[1] sda5[0]
      234372160 blocks [2/2] [UU]
      [===============>.....]  resync = 75.4% (176734976/234372160) finish=12.2min speed=78556K/sec

: 5MB/s(2.5M/s?) for random reads (4k) 3MB/s(1.75M/s?) for random writes (512k) Limits defined in: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt for example: Device Status 0x02 ReadSpeedKBs 0x1000 WriteSpeedKBs 0x1000 (you need to click 'do-not-retest', otherwise it will otherwrite your changes in registy)

http://www.netsplit.com/2007/01/ and http://lightconsulting.com/~thalakan/process-title-notes.html with perl: Sys::Proctitle,

from http://www.nabble.com/Problem-with-temperature-reading-t3265726.html

by David Lissiuk Feb 21, 2007; 07:13pm 

Hi all,

 As I have done fairly extensive testing of various 1-wire issues I can
maybe help shed some light on possible hardware causes of seeing 85.0C
errors for those new to these issues.

In general a 85.0C reading indicates that a POR has occurred in the
chip:

The following issues are common, note that not all are things that
software alone can correct.

1) Poor 1-wire line levels
 A). If the chip is wired for parasitic operation, the VDD line must be
grounded. Otherwise unknown parasitic results may occur. (This is not
required with -PAR devices, which are internally grounded inside the
chip).

 B). While operating under powered mode of operation, the power supply
has to have a reasonably fast rise time, else the chip may enter an
internal test mode.  The voltage should ideally be 5 volts to insure
maximum signal headroom for the 1-wire signal. Line losses through the
cable need to be considered.

 C). The slave device (the DS18B20) may not have enough power/current to
complete the temperature conversion and this may cause a POR to occur in
the chip instead (Generating the 85.0C reading). This may be caused by
the following:

2). Insufficient weak-pull-up current on simple 1-wire bus master
designs
I've seen issues when the weak-pull up current is insufficient, causing
the chip to do a POR during the temp conversion time. Generally a value
between 1.1K and 2.5K for the weak pull-up resistor is what I recommend.
I've often seen this problem on bus master designs using a 4.7K or
greater weaker pull-up resistors.

3) Insufficient conversion time/current.
Parasitic driven devices take considerably longer to do their conversion
than a powered device does (for this reason I generally recommend
powered sensors (See 1WRJ45 for one way how to supply power through a
cable). You will get a 85.0 result if the conversion has not completed
and a POR had occurred previously.

A powered device temperature conversion is typically around 650ms at
12bits (750ms max).  The DS18B20 uses a relatively crude internal timing
oscillator. And variations from both, temperature and internal chip
composition, etc. may effect the duration needed for a successful
temperature conversion cycle to complete, and the chip may draw as much
as 1.5ma during the conversion processes.  This may be why one chip
works and the other doesn't if you're just marginal with the timings.
(generally a good time to redesign your network to fix the fundamental
problems). I have heard of one batch of DS18X20's working in a circuit
and another not due to these slight internal differences on marginal
designed networks. This is not a failure of the parts, just of poor
network design and is generally corrected by insuring sufficient
conversion current is received by the temperature device for the entire
temperature conversion cycle. Powered temperature sensors may also be
polled for when the temperature conversion is complete (thus saving
time). See the datasheet for more information on this.

Another source of errors is too long delays in providing a strong
pull-up current for parasitic device. The sensor is issued a conversion
command, but a strong pull-up current is not applied for one reason or
another and the device loses power. This is only an issue with parasitic
operated devices obviously. It is generally a poor bus master design or
improper programming of the strong pull-up of the bus master.

4), Current supply limitations:
Since during a temperature conversion current use in the device can be
fairly high, (1.5ma max by spec) limitation of the network design may
affect this supplied current.

A). Limitations of the Bus master to supply conversion current.
  A LINK based design bus master can supply more current than a DS2480B
design (DS9097U-S09). A DS2490 (USB) can supply slightly more current
than a DS2480B unit. The Impedance matching line filter on the bus
master must also be considered if added to a DS9097U-S) or USB unit
(Generally a highly recommended practice to add the filter for signal
reflection issues). If the bus master is also parasiticlly powered this
may also be an issue or limitation.

B). Any additional bus line resistance.
The use of a DS2409 adds additional current limiting to what can be
supplied to downstream devices. Each channel of a DS2409 has a different
resistance. So channel use may also effect operation.  In addition the
DS2409 chip package sets the maximum pass-gate current to 20ma max.
according to Dallas (info not in data sheet) This can be a limitation in
any attempt to do bulk temperature conversions of parasitic downstream
devices.

C) Time delays generated by inline devices
A DS2409 can also cause a POR to occur on a temperature sensor after
switching channels using a smart-on command. (There are several errors
in the DS2409 data sheet that I've notified Dallas about, including the
flow diagram. Dallas has verified them and is correcting them in a new
revision of the data sheet. Though I am not sure if all of them will be
corrected by then).

Much of this information has been developed in my efforts on basic
research for a hardware book on 1-wire I am developing in my free time
(Still in early stages of writing, as I have very little of that. I do
however welcome suggestions and reports of problems that need to be
researched (contact me off list)).

I hope this information can be of help by the software writers in
understanding some of the possible conditions that can cause the
reporting of a 85.0C error in the software that should be considered. As
you can see when reporting an 85.0C error it might also be useful to
others to report the bus master used, any line filter, the number and
channels used in any hubs (and the hub design being used), along with
the temperature sensor wiring (powered or parasitic), the delivered
power voltage and the chip revision if known.

Hope this helps the software efforts,
 Cheers

David Lissiuk
Sr. Computer Scientist
Springbok Digitronics 

echo "blacklist intel_agp" >> /etc/modprobe.d/blacklist

(2.2.x) don't forget to procunhide /proc/bus/pci/ and /proc/bus in /etc/vservers/.defaults/apps/vprocunhide/files (create it based on /usr/lib/util-vserver/defaults/vprocunhide-files)

mount /dev/s/usr U && mv usr/* U/ && umount U && mount /dev/s/usr /usr && grep usr /etc/mtab >> /etc/fstab mount /dev/s/var V && mv var/* V/ && umount V && mount /dev/s/var /var && grep var /etc/mtab >> /etc/fstab

RemoteDisplay.vnc.enabled = TRUE RemoteDisplay.vnc.port = 5901 RemoteDisplay.vnc.password = 12345678

# apt-get -o Dir::Etc::SourceList=/etc/apt/security_updates.list -o Dir::State::Lists=/var/lib/xxxxxxx/lists/ update

http://johnbokma.com/mexit/2005/10/26/vmware-player-windows-xp.html

apt-get install module-init-tools apt-get install lvm2

perl -Mre=debug -e "/just|another|perl|hacker/"

Cc: linux-kernel@vger.kernel.org Subject: Re: Production comparison between 2.4.27 and 2.6.8.1 From: rwhron@earthlink.net X-Mailing-List: linux-kernel@vger.kernel.org X-Spam: no; 0.00; comparison:01 i've:01 xfs:01 mount:01 oss:01 sgi:01 dev:01 kernel:01 linux-kernel:01 majordomo:01 vger:01 tux:01 lkml:01 faq:01 size:97 > What can I try to improve performance ? In benchmarks I've done, XFS was helped significantly by the mkfs/mount options in the XFS FAQ. (look for the dbench question). http://oss.sgi.com/projects/xfs/faq.html mkfs -t xfs -l size=32768b -f /dev/device mount -t xfs -o logbufs=8,logbsize=32768 /dev/device /mountpoint

http://www.wormux.org

User-agent: * Disallow:

xset m 6

For xfs, try this:

/dev/hde3 on /var/spool type xfs (rw,noexec,nosuid,noatime,osyncisdsync)

But supposedly the best fs for squid is reiserfs, and you may like those options:

reiserfs (rw,noexec,nosuid,nodev,noatime,nodiratime,notail,block-allocator=noborder)

Nice thing to remember is that squid is very HDD intensive application, so it's rather unwise to run in on anything slower then SCSI (like you can see above I'm running it ;) is asking for trouble... and dumb.

You should also consider oops instead of squid for following reasons:

• oops is more lightweight then squid
• it's way easier to set up and configure.
• oopsctl stat provides hot stats in nice format
• oops can use raw partitions as it's cache.
• oops very quick to stop and start. ( try /etc/init.d/oops restart -> few seconds, try /etc/init.d/squid restart -> few minutes ). And you don't wan't your users waiting for few minutes when you change something simple but requiring restart.
• oops provides special for for transparent proxy ( with squid you can use either transproxy programm, or configure your squid as transproxy, but if you do, prepare for troubles when you use it also as normal proxy)
• squid is rather old code, oops is young and developing vigorously. It's code is cleaner and smaller ( squid is well tested, but contains lots and lots of cruft accumulated for years).
• oops uses single file as it's spool, not some clunky array of arrays of directories. Way easier to manage.

Update:

Based on: http://conferences.oreillynet.com/presentations/os2002/wessels_duane.ppt best filesystem for squid cache is ext2fs, and worst is xfs ( no wonder... ). second best filesystem for squid seems to be reiserfs (notail,noatime), but ext2 is twice as fast as reiserfs in this scenario.

# debugfs -w /dev/sda4
debugfs 1.32 (09-Nov-2002)
debugfs:  features -needs_recovery -has_journal
Filesystem features: dir_index filetype sparse_super
debugfs:  quit

1. Get the toast:

    eyck@hostname:~$ wget -O- http://toastball.net/toast/toast|perl -x - arm toast

   (actually, you shouldn't do that. You should download the toast script, review it to make sure it realy does what is should, and then you can try running it)
2. Prepare the environment:

    eyck@hostname:~$ ln -s .toast/armed/bin/ .

    eyck@hostname:~$ ln -s .toast/armed/man/ .

   Now add something like this to your .bash_profile:

   # set PATH so it includes user's private bin if it exists
   if [ -d ~/bin ] ; then
       PATH=~/bin:"${PATH}"
   fi
   
   # do the same with MANPATH
   if [ -d ~/man ]; then
       MANPATH=~/man:"${MANPATH}"
   fi
   

   And then load it:

    eyck@hostname:~$ . .bash_profile

   Your PATH should look roughly like this: PATH=/home/eyck/bin:/bin:/usr/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/local/bin:/usr/bin
3. Try it out:

    eyck@hostname:~$ toast arm openssh

   After few lines of getting the package... and then compiling it... you should see the results:

    eyck@hostname:~$ bin/ssh -V
   OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.6c 21 dec 2001
   

Congratulations! your toast is now ready to eat. You can now go berzerk:

 eyck@hostname:~$ toast arm mplayer

 eyck@hostname:~$ toast arm fluxbox

 eyck@hostname:~$ toast arm screen