I'm looking for a light-weight chat server/client solution that works with AIX. It also must be free and command-line based.
Goal is to have everyone on a team logged into the same chat server communicating.
I find interesting you can run commands on your VIO server from an HMC:
user@hmc22:~> viosvrcmd -m SN2014AE-FSE -p vio33 -c "lsdev -virtual"
name status description
ent4 Available Virtual I/O Ethernet Adapter (l-lan)
ent5 Available Virtual I/O Ethernet Adapter (l-lan)
vasi0 Available Virtual Asynchronous Services Interface (VASI)
vbsd0 Available Virtual Block Storage Device (VBSD)
vfchost0 Available Virtual FC Server Adapter
vfchost1 Available Virtual FC Server Adapter
vsa0 Available LPAR Virtual Serial Adapter
name status description
ent6 Available EtherChannel / IEEE 802.3ad Link Aggregation
ent7 Available EtherChannel / IEEE 802.3ad Link Aggregation
ent8 Available Shared Ethernet Adapter
ent9 Available Shared Ethernet Adapter
name status description
ent10 Available VLAN
ent11 Available VLAN
In the event you can’t get to the HMC’s gui, you can pretty much do everything from the command line of the HMC. You just need to know how:
Shut down an LPAR:
chsysstate -r lpar -m <MANAGED SYSTEM> -o shutdown --immed -n <LPAR NAME>
Start an LPAR:
chsysstate -r lpar -m <MANAGED SYSTEM> -o on -f <PROFILE NAME> -n <LPAR NAME>
List of the status of all the LPARs on a Managed System:
lssyscfg -m <MANAGED SYSTEM> -r lpar -F name:state
Change the status of a Managed System from an ‘off’ status to an ‘operative’ status:
chsysstate -r sys -m <MANAGED SYSTEM> -o on
Open a text console window:
List all the profiles for all the LPARs on a Managed System:
lssyscfg -r prof -m <Managed System> | cut -d, -f1,2
Want to see how fast your network speeds are between machines/LPARs/etc? This can always be a little tricky to do because there are a lot of factors in plan – and a lot of potential bottlenecks; such as disks.
You can bypass disks ever being touched in your test by connecting via FTP to another server, and sending a block of data directly to /dev/null. This will stop the server from writing it to disk, and therefore give you pure network speeds:
1. Connect to a server via FTP from another server.
2. Enter: put “|dd if=/dev/zero bs=3M count=1000″ /dev/null
3. Monitor the speeds with your favorite monitoring solution topas, top etc.
Previous to AIX 6.1 TL6, if you wanted to change hdisk5 to hdisk1337, you’d have to do some messy ODM cuts in order to change the name.
There is a new command in AIX 6.1 TL6 that allows you change the name of the device as long as it’s not in a VG. This can be VERY useful when setting up HACMP disks, having them the same on both nodes etc.
rendev -l hdisk5 -n hdisk1337
This is a very cool and easy way to debug a problem that is happening in your environment. This is particular useful with highly complex application servers, that are doing and connecting to a lot of different stuff under the hood. I’ve used this method dozens of times to solve problems, where WebSphere was trying to open a file that didn’t exist, and was causing major performance problems for the application underneath. Very cool stuff.
By running perfpmr (IBM performance diagnostics tool) it gathers about 500MB of information.
This will spit out a ton of data that you cannot read, and some you can, because it is compiled in a RAW format.
curt -i trace.raw-0
This will read the compiled raw data. In the application summary, halfway through the file, you will see what PID (and it’s TID – which is what we’re interested in), is containing the highest amount of system CPU time. In this case it looks like:
100.7497 6.6511 94.0986 49.3480 3.2578 46.0903 (667738 4042975)
^ PID ^ TID
Once we have located the PID n TID that is hogging up our system CPU cycles, we need to check out the interval traces which are also compiled and unreadable.
This will output a file called trace.int.
Inside you’ll see exactly what the application was doing. What files it was trying to open etc.
Find out what PID you want to debug (one that’s hung).
Once you have that PID, type: dbx –a THAT_PID
This will bring you into the dbx command line.
Type in thread, you’ll see something similar to:
>$t1 run blocked 417997 k no pro _event_sleep
$t2 wait 0xf10002000101ca08 running 401633 k no pro _ptrgl
$t3 wait 0xf10002000101a208 running 438487 k no pro _ptrgl
If the PID has threaded, it will give you a list of TID’s (Thread ID’s).
You’ll want to look for threads that look abnormal I.E that are in a abnormal state, or in a WAIT or DEADLOCK condition.
To examine a thread, type: thread current and then the number right in front of the $t.
E.G: thread current 2
This will really do nothing, it just sets the attention to that thread.
Next type in x this will give you a thread dump, and you can sometimes see where it is hanging.
Next type in where this can also give you an idea of where it is hanging.
When you are done, type detach to exit out of the dbx session. If you type quit it will exit you out of the session but also kill the original PID.
I have used this to solve a lot of problems where things are hanging. Half of the time it’ll tell me EXACTLY where it is hanging. The one time I did this I found out the process was trying to read a file it didn’t have permission to and two threads were in a dead lock because of it.
I found myself in a situation where I needed to let an application user, su to every user on the system. I knew I’d have to set up a way where the user could su to everyone on the server except root.
I found a solution with sudo:
Add the user in a group called suall, then add this into /etc/sudoers:
I'll be sharing my experiences as a systems engineer, and hopefully some of that information will be useful to people out there. A little background information on moi:
I'm Andy, and I've been doing this for about 4-5 years now. I've worked with everything from F50's to P780's and everything in between. I really love IBM hardware and software, I think it's the most rock solid solution out there! I've run into my fair share of issues in my day, and wish half of the solutions and answers were out in the Internet. Anyway, more to come!