Un(un)mountable file system

After hitting this bug (yes, again and again) I had to unmount the broken file system and run fsck (twice). But then I apparently hit anoter bug (or a feature?) – I could not mount the file system back.

xeon# mount /dev/dsk/c2d0s3 /export/docs
mount: /dev/dsk/c2d0s3 is already mounted or /export/docs is busy

Neither pwdx not lsof showed any processes using /export/docs. The solution was to recreate the directory:

xeon# rm -rf docs
xeon# mkdir docs
xeon# mount /dev/dsk/c2d0s3 /export/docs (after a loooong pause)
xeon# mount | fgrep docs
/export/docs on /dev/dsk/c2d0s3 read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=1980043 on Tue Jul  1 01:07:08 2008

Unkillable process

Snv_92 has been entertaining me since I upgraded from quite stable snv_88. I’m hitting a bug after a bug. (See here).

This is the latest – unkillable process, which can’t be killed with kill -9 or zone reboot. Reboot just hangs. Truss ends up with:

xeon# kill -9 22131
xeon# ps -ef | fgrep 22131
root 22728 5471 0 00:49:27 pts/5 0:00 fgrep 22131
alekz 22131 1 0 20:48:30 zoneconsole 0:03 /opt/sfw/lib/firefox/firefox-bin -P Sun –no-remote
xeon# truss -p 22131
^Ctruss: unanticipated system error: 22131

dtrace shows nothing. The only workaround is to reboot the entire system.

See also:

Revenge of the unkillable process
Unkillable process
Bug ID 6455727

SqueezeCenter and Compress::Zlib

After upgrading to Nevada b92 SqueezeCenter refused to start with the following error:

The following modules failed to load: Compress::Zlib

# perl -MCPAN -e shell
cpan> install Compress::Zlib
. . .
Module [Compress::Zlib] failed to load: is only available with the XS version
. . .

But the actual problem is Scalar::Util. To solve the problem reinstall Scalar::Util and then Compress::Zlib. Use force install if CPAN says that the latest version is already installed:

# perl -MCPAN -e shell
. . .
cpan[1]> install Scalar::Util
CPAN: Storable loaded ok (v2.12)
Going to read /var/tmp/cpan/Metadata
Database was generated on Tue, 24 Jun 2008 10:02:57 GMT
Scalar::Util is up to date (1.19).
cpan[2]> force install Scalar::Util
. . .
cpan[3]> force install Compress::Zlib
. . .

Sources: whirlpool.net.au and Usenet forums.

X libs and X fonts

Alan Coopersmith wrote :

FreeType2 is what converts a TTF or other font file into a pattern of bits displayed on the screen, but it has lots of flags that control how that’s done (anti-aliasing, hinting, LCD optimization, etc.).

Xft2 is the library that calls FreeType to get a bit pattern and then displays that bit pattern on the X server, via either the Render extension or plain Xlib (but plain Xlib is slow).

fontconfig is the library that finds /usr/X11/lib/X11/fonts/TTF/Times.ttf when you ask for “Times Roman 12”. (It’s called by either Xft2 or pango, I forget which.)

pango is the library that calls Xft with a list of glyphs and locations to display them at, after determining what ordering and spacing they should be laid out in, and what glyphs to display for a given character string (which is much easier for English than for languages like Arabic
or Hindi).

GTK+ is the library that applications call to draw their interface on screen (the toolkit), and it calls pango to draw the text portion of those interfaces.

I’m not sure if cairo calls pango or goes direct to Xft2.

What process is using this port?

If lsof is installed in your system:

xeon# lsof 2>/dev/null | fgrep :telnet
telnet    18409    alekz    4u  IPv4 0xffffff0e3b19c740        0t0        TCP xeon:52431->10.0.0.1:telnet (UknownState_-2094513781)

xeon# lsof 2>/dev/null | fgrep :8080
firefox-b   699    alekz   52u  IPv4 0xffffff02db1e0780   0t110637        TCP xeon:51567->dmz:8080 (UknownState_-2094513781)
firefox-b   699    alekz   67u  IPv4 0xffffff0e3b0e06c0   0t127870        TCP xeon:47231->dmz:8080 (UknownState_-2094513781)
squid      2778   nobody    8u  IPv4 0xffffff01dc8ce080        0t0        TCP *:8080 (UknownState_-359969560)
squid      2778   nobody   22u  IPv4 0xffffff01dc6d36c0   0t110637        TCP dmz:8080->xeon:51567 (UknownState_-2094513781)
squid      2778   nobody   41u  IPv4 0xffffff01dc8c26c0   0t127870        TCP dmz:8080->xeon:47231 (UknownState_-2094513781)

If lsof is not installed:

  • Run pfiles /proc/* | less
  • Search for port:
    • Press </>
    • Type port: 23
    • Press <Enter>

The result may look like:

18409:  telnet 10.0.0.1
. . .
4: S_IFSOCK mode:0666 dev:318,0 ino:42212 uid:0 gid:0 size:0
O_RDWR|O_NDELAY
SOCK_STREAM
SO_OOBINLINE,SO_SNDBUF(49152),SO_RCVBUF(49640)
sockname: AF_INET 10.0.0.2  port: 52431
peername: AF_INET 10.0.0.1  port: 23
~
~
~

wine-0.9.59, OpenSolaris and Picasa

New release, new features, new bug fixes and new bugs.
Let’s start with compiling.

Compiling

  • You do not need to use –without-ldap anymore
    I used just two options: –disable-win16 and –without-capi (does anybody use ISDN?).
  • Do not forget the tricks from Part I and Part II
  • New error I haven’t seen before:
    ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include   -DBUILD_SHA1=\"$(GIT_DIR=../../.git git rev-parse HEAD 2>/dev/null)\" -fowinetest.res winetest.rc
    /bin/sh: syntax error at line 1: `(' unexpected
    gmake: *** [winetest.res] Error 2

    Not sure if and why git is needed here, but I simply removed (commented) the following line from programs/winetest/Makefile:

    EXTRARCFLAGS = -DBUILD_SHA1=\"$$(GIT_DIR=$(TOPSRCDIR)/.git git rev-parse HEAD 2>/dev/null)\"

Applications
According to the Announcement, the following bugs (among others) were fixed in 0.9.59:

  • 2866 Support for X11 multi head configurations (Xinerama)
    I use Xinerama, but I haven’t noticed anything wrong about it, it was always working
  • 4528 Firefox vertical size wrong, doesn’t take gnome system menu or task
    bars into account
    Yes, it works correctly now. But Firefox 3 beta 5 crashes every 3 seconds 😉
  • 11574 Picasa cannot upload to web albums
    Still does not work for me. But instead it eats all possible and impossible CPU and memory resources:

    #top
    PID USERNAME LWP PRI NICE  SIZE   RES STATE    TIME    CPU COMMAND
    3731 alekz      9  28    4   26M   12M sleep    2:37   102% wine
    3710 alekz     11  38    4  134M  100M sleep    1:26 99.62% wine
    3713 alekz      1  28    4  109M  106M run     20:32 96.60% wineserver
    . . .

    And this is after I killed Picasa:

    PID USERNAME LWP PRI NICE  SIZE   RES STATE    TIME    CPU COMMAND
    3731 alekz     10   0    4   26M   12M cpu      8:06   102% wine
    3713 alekz      1   0    4  406M  404M cpu     26:46 99.85% wineserver

    I stopped Picasa, one process is gone, but what wine is doing now??! Also look at the consumed memory, it’s constantly increasing.

OpenSolaris Forum

There is a possibility that a Wine Community will be created for OpenSolaris. (aka Nevada, aka Solaris 11). BTW, you can try to use the wine configuring script (see further in the thread), but it does not solve the above mentioned problems, so do not waste your time.

Replacing a DiskSuite (Solaris Volume Manager) disk

A short guide on how to recover a broken DiskSuite mirror.

  1. Check metastat information:
    # metastat -c
    d30              m   34GB d31 (maint) d32
    
      d31 s 34GB c0t0d0s3 (maint) d32 s 34GB c0t1d0s3
    d20 m 4.0GB d21 (maint) d22
      d21 s 4.0GB c0t0d0s1 (maint) d22 s 4.0GB c0t1d0s1
    d10 m 30GB d11 (maint) d12
      d11 s 30GB c0t0d0s0 (maint) d12 s 30GB c0t1d0s0
    hsp001 h -
  2. Remove the broken replicas from the metadb :
    # metadb -i
            flags           first blk       block count
          W   p  l          16              8192            /dev/dsk/c0t0d0s7
          W   p  l          8208            8192            /dev/dsk/c0t0d0s7
         a m  p  luo        16              8192            /dev/dsk/c0t1d0s7
         a    p  luo        8208            8192            /dev/dsk/c0t1d0s7
    . . .
    
    # metadb -d /dev/dsk/c0t0d0s7
  3. Replace the broken disk
  4. Check that the new disk is visible:
    # format
    Searching for disks...done
    
    AVAILABLE DISK SELECTIONS:
    
      0. c0t0d0 /pci@1c,600000/scsi@2/sd@0,0 1. c0t1d0 /pci@1c,600000/scsi@2/sd@1,0
  5. Copy the partition table from the healthy to the new disk:
    # prtvtoc /dev/rdsk/c0t1d0s0 | fmthard -s - \
    /dev/rdsk/c0t0d0s0
    fmthard:  New volume table of contents now in place.
  6. Create metadb replicas (for example, 2 copies in slice 7):
    # metadb -a -c2 /dev/rdsk/c0t0d0s7
  7. Verifying the metadb:
    # metadb -i
    
      flags first blk block count
    a u 16 8192 /dev/dsk/c0t0d0s7 a u 8208 8192 /dev/dsk/c0t0d0s7 a p luo 16 8192 /dev/dsk/c0t1d0s7 a p luo 8208 8192 /dev/dsk/c0t1d0s7
  8. “Metareplace” the failed slices:
    # metastat | fgrep replace
    Invoke: metareplace d30 c0t0d0s3
    Invoke: metareplace d20 c0t0d0s1
    Invoke: metareplace d10 c0t0d0s0
    
    # metareplace -e d30 c0t0d0s3
    d30: device c0t0d0s3 is enabled
    # metareplace -e d20 c0t0d0s1
    d20: device c0t0d0s1 is enabled
    # metareplace -e d10 c0t0d0s0
    d10: device c0t0d0s0 is enabled
    
  9. Periodically check the resyncing status:
    # metastat | fgrep esync
    State: Resyncing
    Resync in progress: 0 % done
    State: Resyncing
    c0t0d0s3          0     No       Resyncing   Yes
    State: Resyncing
    Resync in progress: 19 % done
    State: Resyncing
    c0t0d0s1          0     No       Resyncing   Yes
    State: Resyncing
    Resync in progress: 2 % done
    State: Resyncing
    c0t0d0s0          0     No       Resyncing   Yes