xntpd daemon crashes and fails to start

View previous topic View next topic Go down

xntpd daemon crashes and fails to start

Post by suran on Wed Apr 16, 2008 4:13 am

Sometime in your career, you may have come across a situation where the xntpd daemon cannot start up. The following error is seen in the /var/adm/messages file:

mlockall(): Resource temporarily unavailable
No more memory!

This problem is due to the fact that the system is short on available physical memory. Xntpd is a time critical process and needs to be able to access memory that hasn't been paged out. This is done by locking the memory using the mlockall() call, which causes all of the virtual memory process space to be paged into memory and locked. When there is not enough physical memory available, the mlockall returns with the error "resource temporarily unavailable", thus causing the xntpd daemon to exit.

The solution for this is to have xntpd start early on in the boot process so that other memory intensive application such as sybase, for example do not take up the physical memory i.e lock it out prior to xntpd starting.


Posts : 15
Join date : 2008-04-10

View user profile

Back to top Go down

Re: xntpd daemon crashes and fails to start

Post by tom on Fri Jul 04, 2008 10:19 am

There is a geekier solution which I shall furnish you with here.
Crafted by myself after studying the fantastic Solaris Internals book which you should all own a copy of.

1000 bytes of ugly shell script follow :
# Sort out xntpd failing to restart on Solaris8 when there's a lot of locked memory
# Solaris8 has pages_pp_maximum at ~10% phys mem, it's a conservative 4% on later OS releases.
# Tom Matthews
# ** Not to be run willy-nilly **
ramsize_mb=`prtconf | grep 'Memory' | awk '{print $3}'`
echo "Page size : $page_size"

#convert to pages
pages_installed=`echo $ramsize_mb*1024*1024/$page_size | bc`
echo "RAM total (in pages) : $pages_installed"

#get 4% of the total ram
new_pp_maxval=`echo $pages_installed/100*4 |bc`
echo "4% of which is : $new_pp_maxval"

# grok adb output which trails a CR on Sol8 but not on Sol10
foo=`echo "pages_pp_maximum/E" | adb -k | tail -1`
[ -z "$foo" ] && foo=`echo "pages_pp_maximum/E" | adb -k | tail -2 | head -1`

echo $foo

# Our 4% value will be less than the existing pages_pp_maximum, so we could blat it into the kernel with adb...
# pages_pp_maximum/$write_modify 0t$new_pp_maxval | adb -kw  (/w = 2bytes, /W = 4bytes, /Z=8bytes)

The output will be something like this ...
root:lon0666xus# /var/tmp/xntpd.frig
Page size : 8192
RAM total (in pages) : 2097152
4% of which is : 83884
pages_pp_maximum: 200979

Note that the script will not change anything for you, having any script push new values into a live kernel is dangerous. You'll have to type the final command by hand using the output from the above script. Note the last two lines in the script... our new 4% value _MUST_ be less than pages_pp_maximum or you'll break something.
Assuming it is (and using the example values from above), you can put on your cowboy hat and type the following :
echo "pages_pp_maximum/Z 0t83884" | adb -kw

Now restart your xntpd and you're done !


Posts : 4
Join date : 2008-07-04
Location : London

View user profile http://www.inkhorn.net

Back to top Go down

View previous topic View next topic Back to top

- Similar topics

Permissions in this forum:
You cannot reply to topics in this forum