Find out the size of a directory with du -sk

eepr0143> du -sk /app/SAD/var
7993507 /app/SAD/var


so there you go - totals up all the files under the dir into a summary, displayed in kilobytes (so here the size is roughly 7.5gb)

Troubleshooting a NIC

All the computers in a data center are connected together to form a network . A NIC (Network Interface Card) provides a connection point for a computer. Plug in a network cable, adjust some NIC configuration and some routing configuration and the computer is ready to talk.

When a network goes bad, you need a set of commands to find fast the problem.

First off, obviously is to connect to the server with the problem. If you can't use ssh (or even telnet) to connect through to the management interface, then try logging in to the terminal server. From there you can begin troubleshooting;

run a prtdiag and see if there any hardware issues on the interfaces

check the /var/adm/messages file - for example, if a link keeps going down then up - where does the issue lie? With a cable, a switch port? A NIC?

ndd - for example
ndd /dev/bge1 adv_100fdx_cap link_status link_speed
where
# ndd /dev/interfacename \? --- displays all command options for ndd
# ndd /dev/interfacename link_status --- 0 is down,1 is up.
# ndd /dev/interfacename link_speed --- 0 means 10mbps, 1 means 100mbps
# ndd /dev/hme interfacename --- 0 means half duplex, 1 means full duplex

run a snoop
snoop -d interfacename
this gets all the oputput in promiscuous mode - if transfers are good you get SUCCESS, which would be encouraging...

ifconfig -a
this shows the status of the interface - needs to be UP, RUNNING, BROADCAST, MULTICAST - to determine it is working okay

Look at the traffic that is being seen by that interface. There may be plenty of traffic that is being ignored because it is meant for other hosts. This could mean the cable has been attachd to the wrong virtual network ie. the cable has been plugged into the wrong socket on the firewall.
root@ersds12:>snoop -v -d bge0
Using device /dev/bge (promiscuous mode)
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 1 arrived at 11:39:1.67
...
IP: ----- IP Header -----
IP:
IP: Version = 4
...
IP: Source address = 192.168.18.2, 192.168.18.2
IP: Destination address = 224.0.0.18, 224.0.0.18
IP: No options
...



an excellent link for this sort of stuff;
http://www.planetlarg.net/closed-source/net-solaris-health.htm

legato - some commands - nsrwatch

nsrwatch - this is the one to see a running status of drives and tapes mounted, backups going on, messages etc

the proper format is

nsrwatch -s servername

assigning symmetrix devices to extend a filesystem

when extending filesystems with symmetrix disks

worth checking that the new disks come from the same Symmetrix boxes as the established symmetrix disks - Otherwise they can't be put in the diskgroup for failover.

this is so new devices can be assigned easily in the event of a failover (cluster)

What does the 'old' in the IDLE column when you run a 'who' mean?

old = idle over 24 hours

Kill inactive users

do a who -Hup

look for the PID of the user

kill -9 the user

Kill Inactive and Idle Linux Users

Kill Inactive and Idle Linux Users

Every once in awhile the SSH connection to my Linux server will die and I’ll be left with a dead user. Here’s how I discover the inactive session using the w command:

15:26:26 up 13 days, 23:47, 2 users, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
raam pts/0 wfc-main.wfcorp. Mon10 2days 0.04s 0.04s -bash
raam pts/1 pool-151-199-29- 15:26 0.00s 0.02s 0.01s w
You can easily tell there’s an idle user by glancing at the IDLE column; the user in the first row has been idle for 2 days. There are many ways of killing idle users, but here I’ll show you a few of my favorites. The bottom line is, you need to kill the parent process created by the idle user when he logged in. There are a number of ways of doing that.

Here is how I discover the parent process using the pstree -p command:

├─screen(29380)───bash(29381)───naim(29384)
├─scsi_eh_0(903)
├─sshd(1997)─┬─sshd(32093)─┬─sshd(32095)
│ │ └─sshd(32097)───bash(32098)─┬─mutt(32229)
│ │ └─screen(32266)
│ └─sshd(1390)─┬─sshd(1392)
│ └─sshd(1394)───bash(1395)───pstree(1484)
├─syslogd(1937)
└─usb-storage(904)
We need to find the parent PID for the dead user and issue the sudo kill -1 command. We use the -1 option because it’s a cleaner way of killing processes; some programs, such as mutt, will end cleanly if you kill them with -1. I can see by looking at the tree where I’m running the pstree command, so I just follow that down the tree until I find a common process (branch) shared by both users; this happens to be sshd(1997).

You can see there are two branches at the point — one for my current session and one for the idle session (I know this because I’m the only user logged into this Linux server and because I know I should only have one active session). So I simply kill the sshd(32093) process and the idle user disappears.

Of course, if you’re on a system with multiple users, or you’re logged into the box with multiple connections, using the above method and searching through a huge tree of processes trying to figure out which is which will not be fun. Here’s another way of doing it: Looking at the output from the w command above, we can see that the idle users’ TTY is pts/0 so now all we need is the PID for the parent process. We can find that by running who -all | grep raam:

raam + pts/0 May 10 10:45 . 18076 (wfc-main.wfcorp.net)
raam + pts/1 May 11 15:26 . 1390 (pool-151-199-29-190.bos.east.verizon.net)
Here we can see that 18076 is the PID for the parent process of pts/0, so once we issue kill -1 18076 that idle session will be gone!