Monday, December 29, 2008

Clean-up Dangling Dev Links - sp diff: name finddevice

A couple weeks ago we encountered the "sp diff" message below on bootup. The message iterated about 15-20 times before continuing the final bootup sequence, which took at least twice as long as normal. 

A colleague of mine recalled performing some multipathing activities a few days earlier and thought there might be some dangling dev links as a result. 

To resolve the issue, the devfsadm command was executed in cleanup mode, -C.

sp diff: name finddevice, nargs 1, nret 1,sp 0xf05d35b8 osp 0xf05d35a8
sp diff: name finddevice, nargs 1, nret 1,sp 0xf05d35b8 osp 0xf05d35a8
sp diff: name finddevice, nargs 1, nret 1,sp 0xf05d35b8 osp 0xf05d35a8
sp diff: name finddevice, nargs 1, nret 1,sp 0xf05d35b8 osp 0xf05d35a8
sp diff: name finddevice, nargs 1, nret 1,sp 0xf05d35b8 osp 0xf05d35a8
...

# devfsadm -C -v
# init 6

Update: A message from a colleague who requested not to be named.

stmsboot -e will enable multipathing, the system needs to be rebooted in order for it to take effect.

When the system comes up, you will notice long device names in
/dev/dsk/. It may be coincidence but I noticed that the number of
multipathing devices listed match the number of sp diff lines that are
displayed.

Next, I did a stmsboot -d to disable multipathing and rebooted the
system. When the system came back online, I still saw the sp diff lines.

Lastly, I did the devfsadm -C -v and I saw it clean up the device links. I rebooted the system again and the sp diff lines were gone.

You would think that disabling multipathing should delete the links but
it doesn't.

Friday, December 26, 2008

Use Z-Shell for loop to Compact Argument List

The other day I pinged a number of remote workstations to observe Round Trip Times (RTT) but forgot to eliminate a few series of contiguously numbered remotes that were known to be powered-off. Needless to say, the pinging effort was taking longer than it should have -- I promptly aborted the effort. Here is an example of a compact way of performing this common task using a Z-Shell for loop.

# zsh
# for blog in {1..5} {7..13} {15..22} {27..37}
for> ping -s mysysad$blog 1024 5

Friday, December 12, 2008

My SysAd Blog Temporarily Reverts to its Legacy Blogspot URL

This evening I was checking my web statistics and noticed mysysad.com's traffic had plummeted. At first, I thought it had something to do with me adding a comment widget. You know the deal..."what did you change?" is a common sysad retort. But I quickly realize that was not the issue; it was a DNS issue. Here is a run of the events using the ubiquitous ping command. By the way, I have linked back to sysad several times because I have my very own unsolicited blog scraper.

Checking Google Server (nslookup and ping)

C:\Users\esoft>ping ghs.google.com

Pinging ghs.l.google.com [209.85.171.121] with 32 bytes of data:
Reply from 209.85.171.121: bytes=32 time=128ms TTL=236
Reply from 209.85.171.121: bytes=32 time=155ms TTL=236
Reply from 209.85.171.121: bytes=32 time=129ms TTL=236
Reply from 209.85.171.121: bytes=32 time=155ms TTL=236

Ping statistics for 209.85.171.121:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 128ms, Maximum = 155ms, Average = 141ms

Pinging My SysAd Blog

C:\Users\esoft>ping mysysad.com

Pinging mysysad.com [64.233.179.121] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 64.233.179.121:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Pinging My SysAd Blog but now by IP

C:\Users\esoft>ping 64.233.179.121

Pinging 64.233.179.121 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 64.233.179.121:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Pinging another known Google Server IP (ghs.google.com) for Blogspot

C:\Users\esoft>ping 66.249.81.121

Pinging 66.249.81.121 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 66.249.81.121:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Reverted My SysAd Blog to its legacy Blogspot URL via backend

C:\Users\esoft>ping esofthub.blogspot.com

Pinging blogspot.l.google.com [72.14.207.191] with 32 bytes of data:
Reply from 72.14.207.191: bytes=32 time=182ms TTL=237
Reply from 72.14.207.191: bytes=32 time=207ms TTL=237
Reply from 72.14.207.191: bytes=32 time=181ms TTL=237
Reply from 72.14.207.191: bytes=32 time=179ms TTL=237

Ping statistics for 72.14.207.191:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 179ms, Maximum = 207ms, Average = 187ms

Pinging esofthub.blogspot.com IP

C:\Users\esoft>ping 72.14.207.121

Pinging 72.14.207.121 with 32 bytes of data:
Reply from 72.14.207.121: bytes=32 time=210ms TTL=237
Reply from 72.14.207.121: bytes=32 time=210ms TTL=237
Reply from 72.14.207.121: bytes=32 time=179ms TTL=237
Reply from 72.14.207.121: bytes=32 time=182ms TTL=237

Ping statistics for 72.14.207.121:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 179ms, Maximum = 210ms, Average = 195ms

Edited A-Record settings with my domain registrar, yahoo.com, and then returned My SysAd Blog to www.mysysad.com via Blogger's backend...waited a few minutes

C:\Users\esoft>ping mysysad.com

Pinging mysysad.com [72.14.207.121] with 32 bytes of data:
Reply from 72.14.207.121: bytes=32 time=207ms TTL=239
Reply from 72.14.207.121: bytes=32 time=178ms TTL=239
Reply from 72.14.207.121: bytes=32 time=180ms TTL=239
Reply from 72.14.207.121: bytes=32 time=181ms TTL=239

Ping statistics for 72.14.207.121:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 178ms, Maximum = 207ms, Average = 186ms

C:\Users\esoft>

Here is another domain name issue I had back in April 2008