top

Posts tagged with opensolaris

UFIX column in IPS "pkg list" command

This is something that is not documented. If you do "pkg list" in OpenSolaris 2009.06, there is a column with header "UFIX". This stands for:

U -> upgradable
F -> frozen
I -> incorporated
X -> excludes

Apache unreliable in OpenSolaris 2009.06... workaround available!

Apache 2.2 (Apache's APR actually) has a bug in the OpenSolaris 2009.06 (including Entic.net's OpenSolaris VPS servers) release. The symptom is the web server goes unresponsive and hangs after some time.

We ran Apache in a single thread, in the foreground (httpd -f httpd.conf -X), and then used our trusty PID provider in DTrace to get a stack trace, that looks something like this:

0 80992 apr_atomic_inc32:entry
0 83055 atomic_inc_32_nv:entry
0 83401 port_getn:entry
0 85371 _portfs:entry
2 83394 ___errno:entry
2 80993 apr_atomic_dec32:entry
2 83062 atomic_dec_32_nv:entry
2 83394 ___errno:entry
2 83394 ___errno:entry
2 80853 apr_pollset_poll:entry
2 83124 __div64:entry
2 83121 UDiv:entry
2 83125 __rem64:entry
2 83120 UDivRem:entry
2 80992 apr_atomic_inc32:entry
2 83055 atomic_inc_32_nv:entry
2 83401 port_getn:entry
2 85371 _portfs:entry

Thanks to some great folks over at Sun, we've gotten a workaround that fixes this. The final fix won't be available until APR is upgraded or until build 124.

OpenSolaris 2009.06 Zones and ZFS

Don't mess with the the ZFS cloned BE (boot environments) of the zones using zfs commands. There is very little documentation out there, so here is what we've found with ZFS, zones, and IPS upgrades.

If you have a zone that went through a pkg image-update, you'll notice there are a couple of new cloned ROOT file systems for your zones:

root@vps1:/# zfs get -r mounted,origin,mountpoint zones/tail
NAME PROPERTY VALUE SOURCE
zones/tail mounted yes -
zones/tail origin - -
zones/tail mountpoint /zones/tail default
zones/tail/ROOT mounted no -
zones/tail/ROOT origin - -
zones/tail/ROOT mountpoint legacy local
zones/tail/ROOT/zbe mounted no -
zones/tail/ROOT/zbe origin - -
zones/tail/ROOT/zbe mountpoint legacy local
zones/tail/ROOT/zbe@zbe-1 mounted - -
zones/tail/ROOT/zbe@zbe-1 origin - -
zones/tail/ROOT/zbe@zbe-1 mountpoint - -
zones/tail/ROOT/zbe-1 mounted yes -
zones/tail/ROOT/zbe-1 origin zones/tail/ROOT/zbe@zbe-1 -
zones/tail/ROOT/zbe-1 mountpoint legacy local
root@vps1:/#

Everything below zones/tail/ROOT have a zoned ZFS property. They behave a bit differently, and make it so the zone's can use ZFS root securely. That's good, but what is going on with all of that cloned file systems, the zbe and zbe-1?

zbe is the ROOT fs before the upgrade. zbe-1 is the new ROOT, after the upgrade. zbe-1 is just the clone of the zbe, as indicated with the origin property above, this is great because clones use less disk space.

zbe-1 is the one being used now. In case the global zone was to be reverted back to an original environment, the zone tail will then use zbe as the ROOT fs. This is done automatically when beadm command is used (in the global zone) to manipulate the boot environments. You should not go around destroying the zbe fs in an attempt to clean up disk space. It is tied to the BE of the global zone.

If you have a OpenSolaris VPS with us, and you want to create a snapshot of your zone, we recommend you create a snapshot of the mounted zfs file system above (in this case, you can do: zfs snapshot zones/tail/ROOT/zbe-1@backup). If you create a snapshot of zbe, and you need to restore it, we will not restore it, unless we restore the global zone to that be.

Making sense of Solaris distributions (part 2)

This is an updated version of a similar blog we've written a while back. There are a few different Solaris distributions out there produced both by Sun and the Open source community. Here is a quick run down on the differences. The OS source code is distributed at http://opensolaris.org.

Bleeding Edge - Community/Developer

OpenSolaris 2009.06 (Indiana releases)
* Based on OpenSolaris
* This comes with a live CD
* It is released in a 6 month cycle (or twice a month for Development builds)
* Updates are not available
* Uses IPS packaging: http://pkg.opensolaris.org/dev
* Free

Sun Supported

OpenSolaris 2009.06 (Indiana release, with updates)
* Updates available for 6-18 months through https://pkg.sun.com/opensolaris/support
* Can file bugs and get phone or forum support
* Subscription fee

Solaris 10 5/09 update 7
* Six month updates
* SPARC and x86 platforms
* SRv4 packaging/repo
* Free to download and use

There are also several other Open Solaris distributions. One of which is NexentaOS, a OpenSolaris based OS topped with GNU software.

Update Aug 26th 2009: Removed SXCE, Sun is going to EOL SXCE and go in favor of the Indian Releases for future supported versions of OpenSolaris. That makes much more sense now, never understood why it wanted to have two different forks.

Getting PID from Port in OpenSolaris

LSOF is a tool that's been available for ages, it can be used to "list open files". One of the nice things you can do with it is to list process IDs of a given TCP/UDP port. In Linux, people can use netstat to get this information. Solaris lacked this, so a good alternative is to use LSOF.

The basic command for that is, e.g. to search for port 7009:
lsof -i :7009

That should list the pid plus some other good information regarding that port number. A nice script we came across takes a full netstat output and maps the PID to each port:

#!/bin/sh

LSOF=/usr/local/bin/lsof

printf "%-6s %-10s %-6s %-8s\n" "Port" "Command" "PID" "User"
printf "%-6s %-10s %-6s %-8s\n" "----" "-------" "---" "----"

for PORT in `netstat -an | grep LISTEN | \
perl -ne 'print "$1\n" if /.*\.(\d+)\s+\*\.\*/' | sort -n | uniq`
do
$LSOF -i :${PORT} 2>/dev/null | grep LISTEN | tail -1 | while read line
do
set $line
COMMAND=$1
PID=$2
LSOF_USER=$3
printf "%-6d %-10s %-6d %-8s\n" "$PORT" "$COMMAND" "$PID" "$LSOF_USER"
done
done

Save that to a file, and watch the nice output.

Solaris and OpenSolaris also have similar command, pfiles. You can also use pfiles (though it doesn't do exactly what we want) to lookup all the files and sockets being used by a given process id. You can query all the PIDs running on the system and capture the port number being used.

Another good alternative is using DTrace. It should be pretty easy to make use of say, the net provider, to capture traffic on a given port and then determine the process ID through that. In a future post, we can write up some more information on this.