useradd -u 2372 -s /bin/ksh -c "Thachudayakaimal, Ullas" -d /home/tullas -m tullas
/usr/sbin/groupadd -g 102 weblogic
Showing posts with label Solaris. Show all posts
Showing posts with label Solaris. Show all posts
Friday, December 18, 2009
Tuesday, September 29, 2009
Solaris: Which process is associated with a socket connection?
Consider the following real world scenario (copied from an e-mail message that I got from one of our partners):
[...] one process is waiting for a very long time in a send system call. It is sending on a valid fd but the question we have is that, is there any way to find who is on the other end of that fd? We want to know to which process is that message being sent to. [...]
Here is how I proceed in finding the other end of the socket, and the state of the socket connection with Mozilla's Thunderbird mail client in one end of the socket connection:
Get the process id of the application
% prstat PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 22385 mandalik 180M 64M sleep 49 0 0:05:15 0.1% thunderbird-bin/5
Run pfiles on the pid - it prints a list of open files including open sockets (pfiles is the Solaris supported equivalent of lsof utility).
% pfiles 2238522385: /usr/lib/thunderbird/thunderbird-bin -UILocale C -contentLocale C Current rlimit: 512 file descriptors ... ... 33: S_IFSOCK mode:0666 dev:280,0 ino:31544 uid:0 gid:0 size:0 O_RDWR
O_NONBLOCK SOCK_STREAM SO_SNDBUF(49152),SO_RCVBUF(49640) sockname: AF_INET 192.168.1.2 port: 60364 peername: AF_INET 192.18.39.10 port: 993 ... ...
Locate the socket id and the corresponding sockname/port#, peername/port# in the output of pfiles pid (see step #2).
Here my assumption is that I know the socket id I'm interested in. In the above output, 33 is the socket id. One end of the socket is bound to port 60364 on the local host 192.168.1.2; and the other end of the socket is bound to port 993 on the remote host 192.18.39.10.
Run netstat -a
egrep " /sockport#>/sockport#>/>/sockport#>/>/>>/>/sockport#>/>/>>/>/>>/>>/>>/>
/peerport#>/peerport#>/>/peerport#>/>/>>/>/peerport#>/>/>>/>/>>/>>/>>/>(get the port numbers from step 3); and check the state of the socket connection. If you see anything other than ESTABLISHED, it indicates trouble.
% netstat -a
egrep "60364
993"solaris-devx-iprb0.60364 mail-sfbay.sun.com.993 48460 0 49640 0 ESTABLISHED
If you want to see the host names in numbers (IP addresses), run netstat with option -n.
% netstat -an
egrep "60364
993"192.168.1.2.60364 192.18.39.10.993 49559 0 49640 0 ESTABLISHED
Now since we know both ends of the socket, we can easily get the state of the socket connection at the other end by running netstat -an
egrep ' /localport#>/localport#>/>/localport#>/>/>>/>/localport#>/>/>>/>/>>/>>/>>/>
/remoteport#>/remoteport#>/>/remoteport#>/>/>>/>/remoteport#>/>/>>/>/>>/>>/>>/>
If the state of the socket connection is CLOSE_WAIT, have a look at the following diagnosis: CPU hog with connections in CLOSE_WAIT.
Finally to answer ... which process is that message being sent to ... part of the original question:
Follow the above steps and find the remote host (or IP) and remote port number. To find the corresponding process id on the remote machine to which the other half of the socket belongs to, do the following:
Login as root user on the remote host.
cd /proc
Run pfiles *
egrep "^[0-9]
sockname" > /tmp/pfiles.txt.
vi /tmp/pfiles.txt and search for the port number. If you scroll few lines up, you can see the process ID, name of the process along with its argument(s).
[...] one process is waiting for a very long time in a send system call. It is sending on a valid fd but the question we have is that, is there any way to find who is on the other end of that fd? We want to know to which process is that message being sent to. [...]
Here is how I proceed in finding the other end of the socket, and the state of the socket connection with Mozilla's Thunderbird mail client in one end of the socket connection:
Get the process id of the application
% prstat PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 22385 mandalik 180M 64M sleep 49 0 0:05:15 0.1% thunderbird-bin/5
Run pfiles on the pid - it prints a list of open files including open sockets (pfiles is the Solaris supported equivalent of lsof utility).
% pfiles 2238522385: /usr/lib/thunderbird/thunderbird-bin -UILocale C -contentLocale C Current rlimit: 512 file descriptors ... ... 33: S_IFSOCK mode:0666 dev:280,0 ino:31544 uid:0 gid:0 size:0 O_RDWR
O_NONBLOCK SOCK_STREAM SO_SNDBUF(49152),SO_RCVBUF(49640) sockname: AF_INET 192.168.1.2 port: 60364 peername: AF_INET 192.18.39.10 port: 993 ... ...
Locate the socket id and the corresponding sockname/port#, peername/port# in the output of pfiles pid (see step #2).
Here my assumption is that I know the socket id I'm interested in. In the above output, 33 is the socket id. One end of the socket is bound to port 60364 on the local host 192.168.1.2; and the other end of the socket is bound to port 993 on the remote host 192.18.39.10.
Run netstat -a
egrep "
% netstat -a
egrep "60364
993"solaris-devx-iprb0.60364 mail-sfbay.sun.com.993 48460 0 49640 0 ESTABLISHED
If you want to see the host names in numbers (IP addresses), run netstat with option -n.
% netstat -an
egrep "60364
993"192.168.1.2.60364 192.18.39.10.993 49559 0 49640 0 ESTABLISHED
Now since we know both ends of the socket, we can easily get the state of the socket connection at the other end by running netstat -an
egrep '
If the state of the socket connection is CLOSE_WAIT, have a look at the following diagnosis: CPU hog with connections in CLOSE_WAIT.
Finally to answer ... which process is that message being sent to ... part of the original question:
Follow the above steps and find the remote host (or IP) and remote port number. To find the corresponding process id on the remote machine to which the other half of the socket belongs to, do the following:
Login as root user on the remote host.
cd /proc
Run pfiles *
egrep "^[0-9]
sockname" > /tmp/pfiles.txt.
vi /tmp/pfiles.txt and search for the port number. If you scroll few lines up, you can see the process ID, name of the process along with its argument(s).
Tuesday, August 11, 2009
Sending mail from unix box with attachment
First create the message in a text file and give below command
mailx -s "SQL File you requested" t.ullas@gmail.com < message |/usr/bin/uuencode sql.zip sql.zip >> message
mailx -s "SQL File you requested" t.ullas@gmail.com < message |/usr/bin/uuencode sql.zip sql.zip >> message
Thursday, July 23, 2009
Advanced Solaris Command
Process stats
– cputrack - per-processor hw counters
– pargs – process arguments
– pflags – process flags
– pcred – process credentials
– pldd – process's library dependencies eg.pldd `pgrep syslog`
– psig – process signal disposition
– pstack – process stack dump eg. pstack `pgrep syslog`
– pmap – process memory map
– pfiles – open files and names
– prstat – process statistics
– ptree – process tree
– ptime – process microstate times
– pwdx – process working directory
Process control
– pgrep – grep for processes
– pkill – kill processes list
– pstop – stop processes
– prun – start processes
– prctl – view/set process resources
– pwait – wait for process
– preap – reap a zombie process
- pfiles - Find Files Opened by a Process eg. pfiles `pgrep syslog` | pg
Process tracing/debugging
– abitrace – trace ABI interfaces
– dtrace – trace the world
– mdb – debug/control processes
– truss – trace functions and
system calls
Kernel tracing/debugging
– dtrace – trace and monitor kernel
– lockstat – monitor locking statistics
– lockstat -k – profile kernel
– mdb – debug live and kernel cores
System stats
– acctcom – process accounting
– busstat – Bus hardware counters
– cpustat – CPU hardware counters
– iostat – IO & NFS statistics
– kstat – display kernel statistics
– mpstat – processor statistics
– netstat – network statistics
– nfsstat – nfs server stats
– sar – kitchen sink utility
– vmstat – virtual memory stats
– cputrack - per-processor hw counters
– pargs – process arguments
– pflags – process flags
– pcred – process credentials
– pldd – process's library dependencies eg.pldd `pgrep syslog`
– psig – process signal disposition
– pstack – process stack dump eg. pstack `pgrep syslog`
– pmap – process memory map
– pfiles – open files and names
– prstat – process statistics
– ptree – process tree
– ptime – process microstate times
– pwdx – process working directory
Process control
– pgrep – grep for processes
– pkill – kill processes list
– pstop – stop processes
– prun – start processes
– prctl – view/set process resources
– pwait – wait for process
– preap – reap a zombie process
- pfiles - Find Files Opened by a Process eg. pfiles `pgrep syslog` | pg
Process tracing/debugging
– abitrace – trace ABI interfaces
– dtrace – trace the world
– mdb – debug/control processes
– truss – trace functions and
system calls
Kernel tracing/debugging
– dtrace – trace and monitor kernel
– lockstat – monitor locking statistics
– lockstat -k – profile kernel
– mdb – debug live and kernel cores
System stats
– acctcom – process accounting
– busstat – Bus hardware counters
– cpustat – CPU hardware counters
– iostat – IO & NFS statistics
– kstat – display kernel statistics
– mpstat – processor statistics
– netstat – network statistics
– nfsstat – nfs server stats
– sar – kitchen sink utility
– vmstat – virtual memory stats
Monday, July 13, 2009
Goo FAQ on Unix/Solaris
This is a good website
http://www.unixguide.net/sun/faq/
http://www.unixguide.net/sun/faq/
Tuesday, July 07, 2009
How do I save or redirect stdout and stderr into different files?
Q. I need to run a program called oraMon.pl. However this program is run from cron job. It report error to stderr and normal output to stdout. How do I save stdout, stderr and both into 3 separate log files?
A. It is not that hard if you know howto redirect stderr, stdout and a small command called tee.
=> fd0 is stdin
=> fd1 is stdout
=> fd2 is stderr
There are two formats for redirecting standard output and standard error:
&>word
and
>&word
For example anything written to fd2 to the same place as output to fd1, you will use:
2>&1
tee command read from standard input and write to standard output and file.
So to send stderr to /tmp/errors.log, stdout to /tmp/output.log and both to /tmp/final.log, type as follows:
((/path/to/oraMon.pl 2>&1 1>&3 | tee /tmp/errors.log) 3>&1 1>&2 | tee /tmp/output.log) > /tmp/final.log 2>&1
A. It is not that hard if you know howto redirect stderr, stdout and a small command called tee.
=> fd0 is stdin
=> fd1 is stdout
=> fd2 is stderr
There are two formats for redirecting standard output and standard error:
&>word
and
>&word
For example anything written to fd2 to the same place as output to fd1, you will use:
2>&1
tee command read from standard input and write to standard output and file.
So to send stderr to /tmp/errors.log, stdout to /tmp/output.log and both to /tmp/final.log, type as follows:
((/path/to/oraMon.pl 2>&1 1>&3 | tee /tmp/errors.log) 3>&1 1>&2 | tee /tmp/output.log) > /tmp/final.log 2>&1
All about Unix Date command
Convert unix timestamp to date
# date -d @1221256800 "+%Y-%m-%d %T"
2008-09-13 00:00:00
Convert a date (YYYYMMDD) to unix timestamp
# date -d "20080913" +%s
1221256800
# date -d @1221256800 "+%Y-%m-%d %T"
2008-09-13 00:00:00
Convert a date (YYYYMMDD) to unix timestamp
# date -d "20080913" +%s
1221256800
mtime ctime and atime
Unix keeps 3 timestamps for each file: mtime, ctime, and atime. Most people seem to understand atime (access time), it is when the file was last read. There does seem to be some confusion between mtime and ctime though. ctime is the inode change time while mtime is the file modification time. "Change" and "modification" are pretty much synonymous. There is no clue to be had by pondering those words. Instead you need to focus on what is being changed. mtime changes when you write to the file. It is the age of the data in the file. Whenever mtime changes, so does ctime. But ctime changes a few extra times. For example, it will change if you change the owner or the permissions on the file.
Let's look at a concrete example. We run a package called Samba that lets PC's access files. To change the Samba configuration, I just edit a file called smb.conf. (This changes mtime and ctime.) I don't need to take any other action to tell Samba that I changed that file. Every now and then Samba looks at the mtime on the file. If the mtime has changed, Samba rereads the file. Later that night our backup system runs. It uses ctime, which also changed so it backs up the file. But let's say that a couple of days later I notice that the permissions on smb.conf are 666. That's not good..anyone can edit the file. So I do a "chmod 644 smb.conf". This changes only ctime. Samba will not reread the file. But later that night, our backup program notices that ctime has changes, so it backs up the file. That way, if we lose the system and need to reload our backups, we get the new improved permission setting.
Here is a second example. Let's say that you have a data file called employees.txt which is a list of employees. And you have a program to print it out. The program not only prints the data, but it obtains the mtime and prints that too. Now someone has requested an employee list from the end of the year 2000 and you found a backup tape that has that file. Many restore programs will restore the mtime as well. When you run that program it will print an mtime from the end of the year 2000. But the ctime is today. So again, our backup program will see the file as needing to be backed up.
Suppose your restore program did not restore the mtime. You don't want your program to print today's date. Well no problem. mtime is under your control. You can set it to what ever you want. So just do:
$ touch -t 200012311800 employees.txt
This will set mtime back to the date you want and it sets ctime to now. You have complete control over mtime, but the system stays in control of ctime. So mtime is a little bit like the date on a letter while ctime is like the postmark on the envelope.
The find command uses arguments like:
-mtime -2
-mtime +2
-mtime 2
There are -ctime and -atime options as well. Since we now understand the differences among mtime, ctime, and atime, by understanding how find uses the -mtime option, the other two become understood as well. So I will describe find's use of the -mtime option.
As you probably know, the find command can run for minutes or hours depending on the size of the filesystem being searched. The find command makes a note of its own start time. It then looks at a file's mtime and computes how many seconds ago the file was modified. By dividing the seconds by 86,400 (and discarding any remainder), it can calculate the file's age in days:
Code:
0 days in seconds: 0 - 86399
1 day in seconds: 86400 - 172799
2 days in seconds: 172800 - 259159
So now that we know how many days ago a file was modified, we can use stuff like "-mtime 2" which specifies files that are 172800 to 259159 seconds older than the instant that the find command was started.
"-mtime -2" means files that are less than 2 days old, such as a file that is 0 or 1 days old.
"-mtime +2" means files that are more than 2 days old... {3, 4, 5, ...}
It may seem odd, but +0 is supposed to work and would mean files more than 0 days old. It is very important to recognize that find's concept of a "day" has nothing to do with midnight.
Let's look at a concrete example. We run a package called Samba that lets PC's access files. To change the Samba configuration, I just edit a file called smb.conf. (This changes mtime and ctime.) I don't need to take any other action to tell Samba that I changed that file. Every now and then Samba looks at the mtime on the file. If the mtime has changed, Samba rereads the file. Later that night our backup system runs. It uses ctime, which also changed so it backs up the file. But let's say that a couple of days later I notice that the permissions on smb.conf are 666. That's not good..anyone can edit the file. So I do a "chmod 644 smb.conf". This changes only ctime. Samba will not reread the file. But later that night, our backup program notices that ctime has changes, so it backs up the file. That way, if we lose the system and need to reload our backups, we get the new improved permission setting.
Here is a second example. Let's say that you have a data file called employees.txt which is a list of employees. And you have a program to print it out. The program not only prints the data, but it obtains the mtime and prints that too. Now someone has requested an employee list from the end of the year 2000 and you found a backup tape that has that file. Many restore programs will restore the mtime as well. When you run that program it will print an mtime from the end of the year 2000. But the ctime is today. So again, our backup program will see the file as needing to be backed up.
Suppose your restore program did not restore the mtime. You don't want your program to print today's date. Well no problem. mtime is under your control. You can set it to what ever you want. So just do:
$ touch -t 200012311800 employees.txt
This will set mtime back to the date you want and it sets ctime to now. You have complete control over mtime, but the system stays in control of ctime. So mtime is a little bit like the date on a letter while ctime is like the postmark on the envelope.
The find command uses arguments like:
-mtime -2
-mtime +2
-mtime 2
There are -ctime and -atime options as well. Since we now understand the differences among mtime, ctime, and atime, by understanding how find uses the -mtime option, the other two become understood as well. So I will describe find's use of the -mtime option.
As you probably know, the find command can run for minutes or hours depending on the size of the filesystem being searched. The find command makes a note of its own start time. It then looks at a file's mtime and computes how many seconds ago the file was modified. By dividing the seconds by 86,400 (and discarding any remainder), it can calculate the file's age in days:
Code:
0 days in seconds: 0 - 86399
1 day in seconds: 86400 - 172799
2 days in seconds: 172800 - 259159
So now that we know how many days ago a file was modified, we can use stuff like "-mtime 2" which specifies files that are 172800 to 259159 seconds older than the instant that the find command was started.
"-mtime -2" means files that are less than 2 days old, such as a file that is 0 or 1 days old.
"-mtime +2" means files that are more than 2 days old... {3, 4, 5, ...}
It may seem odd, but +0 is supposed to work and would mean files more than 0 days old. It is very important to recognize that find's concept of a "day" has nothing to do with midnight.
Thursday, April 16, 2009
Some very good Links for Unix Server Admins
http://www.crucialp.com/resources/tutorials/dedicated-server/
Subscribe to:
Posts (Atom)