Sam Pointer

When installing Sendmail from the repository packages it is pretty much assumed that you will only be running one instance on a given server. If, like I had to recently, you want to maintain a number of sendmail configurations and process, but want to fit into the Debian rc script scheme, it takes a bit of work.

I’ve created a patch that can be run against the stock /etc/init.d/sendmail script to produce scripts like /etc/init.d/sendmail.mail1 to manage named instances of sendmail. There are a few things you need to know:

• The patched scripts expects to find the configuration for the named instances in /etc/mail/servers/instancename
• The script expects to be called sendmail.instancename
• Along with changing the INSTANCE= variable at the top of the script, be sure to change the comments so that the update-rc.d style daemon registration works if required. A global search and replace is probably your best bet.
• /etc/default/sendmail can be copied to /etc/default/sendmail.instancename and populated, if present or required.
• PID and lock files end up in /var/run/sendmail.instancename. You will need to edit your named instances sendmail.mc/cf to have the PID files created in the correct location. Spools end up in /var/spool/mqueue.instancename

The final piece of configuration required to make this mechanism work is to copy /etc/mail/sendmail.conf to /etc/mail/servers/instancename/sendmail.conf and to modify the MISC_PARMS variable:

MISC_PARMS="-C/etc/mail/servers/INSTANCENAME/sendmail.cf"

Substituting INSTANCENAME as required. This ensures that the correct configuration file is read from.

If you are binding your sendmail instances to different interfaces you might like to also modify the DAEMON_NETIF variable to have the instance watch the correct interface for state changes, if you have DAEMON_NETMODE set to something other than the default “Static”.

Apart from that the patched script does everything that you would expect and the various logged messages reflect the instance name. Managing individual instances then becomes a matter of:

$ sudo service sendmail.mail3 stop
$ sudo service sendmail.mail2 start

Easy as that.

I’ve wasted quite a bit of time today due to a nasty bug manifesting itself in Aptana Studio. I’m using the 64 bit Linux standalone version.

I recently configured a new project. I installed the RadRails and Subclipse, updated my gems to Rails 2.3.2. Good to go. I checked the project out from Subversion, configured a server and continued development. The next time I started Aptana the VM dumped an hs_err_pid4272.log in my home directory..

The pertinent string is

tack: [0x00007fffb511f000,0x00007fffb531f000),  sp=0x00007fffb53191b0,  free space=2024k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libgdk-x11-2.0.so.0+0x3a4d0]  gdk_window_process_updates+0xe0

The only way I can work around this is to remove my default workspace directory and start from scratch.

This is logged as a bug here on the Aptana support forums.

Looking at the hs_err_pid4849.log also attached to the ticket, you can see that his permgen is full, as Chris Williams says.

Heap
 def new generation   total 2944K, used 2180K [0x74090000, 0x743c0000, 0x75440000)
  eden space 2624K,  71% used [0x74090000, 0x74264d58, 0x74320000)
  from space 320K,  95% used [0x74370000, 0x743bc5d8, 0x743c0000)
  to   space 320K,   0% used [0x74320000, 0x74320000, 0x74370000)
 tenured generation   total 37824K, used 17682K [0x75440000, 0x77930000, 0x84090000)
   the space 37824K,  46% used [0x75440000, 0x76584b30, 0x76584c00, 0x77930000)
 compacting perm gen  total 29440K, used 29209K [0x84090000, 0x85d50000, 0x94090000)
   the space 29440K,  99% used [0x84090000, 0x85d167a8, 0x85d16800, 0x85d50000)
    ro space 8192K,  74% used [0x94090000, 0x94688b48, 0x94688c00, 0x94890000)
    rw space 12288K,  58% used [0x94890000, 0x94fa3df0, 0x94fa3e00, 0x95490000)

I tried amending my permgen to ensure that I wasn’t suffering from the same (possible) problem. I edited my AptanaStudio.ini and upped the –launcher.XXMaxPermSize value from 256m to 512m.

Heap
 PSYoungGen      total 125760K, used 59990K [0x00007f1b7a760000, 0x00007f1b83d10000, 0x00007f1ba5200000)
  eden space 114560K, 42% used [0x00007f1b7a760000,0x00007f1b7d715b18,0x00007f1b81740000)
  from space 11200K, 99% used [0x00007f1b83220000,0x00007f1b83d00048,0x00007f1b83d10000)
  to   space 16832K, 0% used [0x00007f1b81c30000,0x00007f1b81c30000,0x00007f1b82ca0000)
 PSOldGen        total 69056K, used 27327K [0x00007f1b25200000, 0x00007f1b29570000, 0x00007f1b7a760000)
  object space 69056K, 39% used [0x00007f1b25200000,0x00007f1b26caffe0,0x00007f1b29570000)
 PSPermGen       total 75840K, used 48917K [0x00007f1b05200000, 0x00007f1b09c10000, 0x00007f1b25200000)
  object space 75840K, 64% used [0x00007f1b05200000,0x00007f1b081c5500,0x00007f1b09c10000)

As you can see, its 64% full.

I’m using the following:

Java version "1.5.0_18"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_18-b02)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_18-b02, mixed mode)


Linux sam-desktop 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 22:12:12 UTC 2009 x86_64 GNU/Linux

I’d be very greatful to anyone who has any ideas what’s going here. Being primarily a production engineer and not a Java developer I did run strace on the thing, with -f to follow the children. Suffice to say I found myself bashing out a magic SysRq and ‘o’ combo.