Solaris 10 Boot Failure

OK, so this has now bitten me twice on a new install. Basically, put Solaris 10u5 on certain machines, and it will work fine until you edit the /etc/vfstab and forget to add a terminating newline to one of your entries. Upon reboot you will get something like this: Error: svc:/system/filesystem/root:default failed to mount /boot (see 'svcs -x' for details)[ system/filesystem/root:default failed fatally (see 'svcs -x' for details) ]Requesting System Maintenance ModeConsole login service(s) cannot runAt the top of the output from svcs, you’ll see:svc:/system/filesystem/root:default (root file system mount)Reason: Start method exited with $SMF_EXIT_ERR_FATALsee: /etc/svc/volatile/system-filesystem-root:default.logImpact: 44 dependent services are not running. (use -v for list.)The problem is that missing newline, which means the mount table is never parsed correctly. To fix, enter your root password to get into admin mode. You’ll need to first remount the root fs as read/write: # mount -orw,remountAnd then add that offending missing line end: # echo >>/etc/vfstabBe careful with that second line; miss a > symbol and you’ll wipe out your vfstab altogether. Now reboot, and things should be back to normal.

MySQL on i5/OS

i5/OS doesn’t immediately strike you as the most natural environment for running MySQL, but in fact, there some advantages and benefits of making use of the hardware and i5/OS environment. The System i environment used with i5/OS is scalable, and the i5/OS itself provides lots of benefits over the control and separate of work. Obviously another key advantage is that if you are already using i5/OS for your application, then being able to plug in MySQL into that equation on the same machine makes a big difference. For those companies and organizations that already have a business application on their server, you can use MySQL in combination with ODBC or more direct interfaces such as PHP to provide a web interface to your business application all in the same box. MySQL works through PASE (Portable Application Solutions Environment) which allows AIX applications to run directly on i5/OS through a direct application binary interface. As a supported platform for MySQL 5.0 we obviously have instructions for installing MySQL into your i5/OS environment. Once installed, MySQL on i5/OS works just like any other MySQL installation. However, if you want a more complete view of the support, environment, and deployment of MySQL on i5/OS and more detailed instructions for setting PASE and your system to accept MySQL, then check out the IBM Redbook Discovering MySQL on IBM i5/OS.

Mysterious crashes? – check your temporary directory settings

Just recently I seem to have noticed an increased number of mysterious crashes and terminations of applications. This is generally on brand new systems that I’m setting up, or on existing systems where I’m setting up a new or duplicate account. Initially everything is fine, but then all of a sudden as I start syncing over my files, shell profile and so on applications will stop working. I’ve experienced it in MySQL, and more recently when starting up Gnome on Solaris 10 9/07. Sometimes the problem is obvious, other times it takes me a while to realize what is happening and causing the problem. But in all cases it’s the same problem – my TMPDIR environment variable points to a directory that doesn't exist. That's because for historical reasons (mostly related to HP-UX, bad permissions and global tmp directories) I've always set TMPDIR to a directory within my home directory. It's just a one of those things I've had in my bash profile for as long as I can remember. Probably 12 years or more at least. This can be counterproductive on some systems - on Solaris for example the main /tmp directory is actually mounted on the swap space, which means that RAM will be used if it’s available, which can make a big difference during compilation. But any setting is counterproductive if you point to a directory that doesn’t exist and then have an application that tries to create a temporary file, fails, and then never prints out a useful trace of why it had a problem (yes, I mean you Gnome!). I’ve just reset my TMPDIR in .bash_vars to read:

case $OSTYPE in (solaris*) export set TMPDIR=/tmp/mc;mkdir -m 0700 -p $TMPDIR ;; (*) export set TMPDIR=~/tmp;mkdir -m 0700 -p $TMPDIR ;;esac

Now I explicitly create a directory in a suitable location during startup, so I shouldn’t experience those crashes anymore.