https://bugzilla.novell.com/show_bug.cgi?id=221948 Summary: load of bind during boot fails if ip-up starts modify_resolvconf at the same time. Product: SUSE Linux 10.1 Version: Final Platform: Other OS/Version: SuSE Linux 10.1 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: ulrich@holeschak.de QAContact: qa@suse.de Loading of bind (named) could fail during boot, if ip-up calls /sbin/modify_resolvconf at the same time (when using a DSL connection and modification of named.conf is enabled). modify_resolvconf calls "/etc/init.d/named reload". If this ist done EXACTLY at the same time when the boot process tries to start bind the start of bind fails. Normally this is happening very seldom, but on my machine this did happen very often. If have solved this by adding the following lock mechanism to the start section of /etc/init.d/named: --------------------------------------------- LOCKFILE="/var/lock/named.pid" removefiles=() declare -a removefiles function removeonexit() { removefiles[${#removefiles[@]}]="$1" } function cleanup() { local file for file in "${removefiles[@]}"; do rm -f "$file" done } trap cleanup EXIT function lockMessage() { tput bold echo -en "\nWarning: " tput sgr0 echo -e "$1 " } function setlock() { ### Locking mechanism LOCKED=0 while [ $LOCKED -eq 0 ]; do set -o noclobber echo "$$" 2> /dev/null > $LOCKFILE set +o noclobber read PID < $LOCKFILE if [ "$PID" != "$$" ]; then lockMessage "Another rcnamed with PID $PID found, waiting ..." i=0 while [ -e "$LOCKFILE" -a "$i" -lt 15 ]; do sleep 1 i=$(( i + 2 )) done if [ -e "$LOCKFILE" ]; then lockMessage "Lockfile is still there, ignoring it ..." kill -TERM $PID sleep 2 kill -KILL $PID rm -f "$LOCKFILE" fi else LOCKED=1 removeonexit "$LOCKFILE" fi done } setlock --------------------------------------------- The code is basically taken from SueFirewall2, but is improved a bit. I contrast to SuseFirewall2 i try to write the lockfile FIRST and then check if this writing was possible. This prevents race conditions if multiple instances of this code try to lock a the same time ... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.