Being Cellfish : *nix

pthread_cond_timedwait behaving differently on different platforms

cellfish — Tue, 01 Sep 2009 19:01:00 GMT

pthread_cond_timedwait is a nice little function that can be used to "atomically" release a mutex, wait for a condition with a timeout and then acquire the mutex. The first pitfall of this method is that the "timeout" is an absolute time, not a relative time as with most timeouts. Other than that it works fine for most platforms I've encountered. Until I used it on a BSD based system. Suddenly the code did not work in some cases. I managed to track it down to the situation where the time had already passed in which case I got odd behavior.

Turns out most platforms implement this method in a way so that if the time have passed, the mutex is released and reacquired immediately (an assumption used in the code I was working on), but on BSD this is not the case. For most platforms the MAN-page clearly states that this is the case (i.e. release and reacquire the mutex) but for BSD it says nothing about it. I can only assume there is an optimization in the code skipping the release-reacquire action if the time have already passed. I think that is an odd behavior since it blocks any other threads waiting for that mutex (unless you work around it with an extra release-acquire scheme).

So know your APIs and be careful if you're writing code for several platforms. And I can ensure that a number of unit tests exploring the behavior of an API can save time trouble shooting differences like this.

Mounting a file system to an FTP server

cellfish — Sun, 17 May 2009 06:20:00 GMT

I recently needed to move all my private domains to a new hosting solution and the new solution did not allow any other access than FTP. I considered setting up a mirror on my ubuntu host at home but that didn't feel like the best solution. So I thought there must be a way to mount a file system using FTP. And there is several I think. The one I tested and that looks good so far is curlftpfs. The only tweak not mentioned on the curlftpfs site (in an obvious place) is that you need to put the following in your /etc/fstab to make sure all users (and not just root) have access to the mounted file system:

curlftpfs#ftp-user:ftp-password@ftp-host /mount/point fuse rw,uid=500,user,allow_other,noauto 0 0

"allow_other" is the magic enabling all users access. Since it uses FTP under the hood you will notice the file system is quite slow at times. Especially when editing large files. But compared with having a local mirror and updating all changed files when needed I think this a pretty convenient way to access the files on the FTP server.

A reminder if you want to read/write your file in non blocking mode (in C(++))

cellfish — Thu, 16 Apr 2009 14:16:00 GMT

Sometimes you might want to read a file non-blocking. It could be /dev/random because waiting for entropy might take very long. Also when you have to read device files on unix you sometimes have to read them non-blocking. A common pattern is to open the file non-blocking using the open method: open(..., O_NONBLOCK, ...)

This however may be a problem. This type of open will typically succeed (because the system is opening the file non-blocking) and when you then start reading (or writing) you get a failure. The failure can be anything from permission problems to unavailable devices. This is how non-blocking I/O works and something you're well aware of if you're using sockets for communication but since "this is files" you might forget to take non-blocking into account.

So there is a really easy way to work around this. Files, unlike network sockets completes the open operation very fast. So making the open call non-blocking generally does not make so much sense. Instead I suggest you open the file in blocking mode and then change it to non-blocking one opened. And this is how you do that:


   1:  int fd = open(..., 0, ...); // Filed open in blocking
   2:  int fd_flags = fcntl(fd, F_GETFL);
   3:  if (fd_flags < 0) { // Get any flags set on the fd.
   4:      close(fd);
   5:      return error;
   6:  }
   7:  if (-1 == fcntl(fd, F_SETFL, fd_flags | O_NONBLOCK)) { // Add non blocking to the fd flags
   8:      close(fd);
   9:      return error;
  10:  }

But there is (at least) one situation where a non-blocking open might make some sense. That is when you open a file on a remote server and you cannot afford the waiting of an open call. And in this case you must treat the file descriptor like any other file descriptor used for network communication and use select to make sure the file descriptor is ready before you start using it.

Fixing disk configuration/statistics mismatch on HPUX

cellfish — Fri, 10 Apr 2009 14:10:00 GMT

I recently was involved in troubleshooting a problem on a HPUX system.It turned out that the system command iostat showed one disk and the configuration (/etc/lvmtab) showed another disk. Yet another symptom was that lvdisplay didn't work at all. Since there had been a bunch of activity on that system it took some detective work to find out that the reason for the problem was that the raid controller had been replaced.

So this still amazes me. The configuration said one thing and the monitoring tools another but still the host worked just fine. Actually it was a little slow but apparently the mix-up of disk devices didn't matter. So when other systems have their hardware changed you need to rescan it so how do you do that on HPUX? Well this is how you fix your disk configuration if you have one volume group named "vg00":

In multiuser mode:
#/sbin/vgexport -m /vg00.map -s -p -v vg00

Reboot the system and go to maintenance mode:
#shutdown -ry 0 [Esc]

Main Menu: boot pri isl
Interact with the IPL?> y
ISL> hpux –lm

#/sbin/vgexport -v vg00
#/sbin/mkdir /dev/vg00

Create the special device file (SDF), use the next available minor number:
#/sbin/mknod /dev/vg00/group c 64 0x##0000
#/sbin/vgimport -m /vg00.map -N -v -s vg00 vgchange -a y vg00

Reboot the system to multiuser mode again.

Preemptive comment response: No I don't know why the system was not reconfigured immediately after replacing the RAID controller. Probably because everything seamed to work after booting.