Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 43642 - Setiathome Init script and Setiwrapper bugs on a dual opteron
Summary: Setiathome Init script and Setiwrapper bugs on a dual opteron
Status: RESOLVED DUPLICATE of bug 40120
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: High normal (vote)
Assignee: AMD64 Project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-03 13:42 UTC by Marius Caldas
Modified: 2005-07-17 13:06 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marius Caldas 2004-03-03 13:42:43 UTC
I just updated to setiathome-3.08-r2 on a dual Opteron. I then started it with the init script and noticed a couple of bugs. The first bug is cosmetic. The init script outputs the following message if it notices the user hasn't logged in yet:

root # /etc/init.d/setiathome start
 * Re-caching dependency info (mtimes differ)...
 * Please setup SETI@home first by running the following commands:
 * cd /var/lib/setiathome
 * /var/lib/setiathome/setiathome -login 

The last line should be:

 * /opt/setiathome/setiathome -login 

Which means the Init script, at line 21,

  eerror ${SETIATHOME_DIR}/setiathome -login ${SETIATHOME_OPTIONS}

should be changed to:

  eerror ${SETIBINDIR}/setiathome -login ${SETIATHOME_OPTIONS}.

I don't think you need to pass the SETIATHOME_OPTIONS when logging in.

The second bug is much more serious. I started two threads on a dual Opteron, and everything seemed to be fine. I then started "top" to inspect CPU and memory consumption. To my surprise, there was only one thread running, and there was a setiwrapper process that was consuming 12% of the second CPU. I looked at the /var/lib/setiathome/thread2 directory and I found an enormous setiathome.log file, at about 48 Megs and growing. I stopped the seti process and peeked at the log file:
...
another instance of SETI@home is running in this directory.
Each instance of SETI@home must run in a separate directory.
/var/lib/setiathome/setiwrapper: line 7: wait: pid 1 is not a child of this shell
Couldn't get lock file.  This is probably because
another instance of SETI@home is running in this directory.
Each instance of SETI@home must run in a separate directory.
/var/lib/setiathome/setiwrapper: line 7: wait: pid 1 is not a child of this shell
Couldn't get lock file.  This is probably because
another instance of SETI@home is running in this directory.
Each instance of SETI@home must run in a separate directory.

The proble seems to be in the following code, in lines 46-53 of the init script:

	for thread in `seq 1 "${SETIATHOME_THREADS}"`; do
		cd "${SETIATHOME_DIR}"
		if [ "${thread}" != '1' ]; then
			cd "thread${thread}"
		fi

		${SETIATHOME_DIR}/setiwrapper ${SETIBINDIR} ${SETIATHOME_OPTIONS} >& setiathome.log &
	done

It is apparently starting all threads at the last "threadX" directory.

Reproducible: Always
Steps to Reproduce:
1.emerge setiathome
2./etc/init.d/setiathome start
root # /etc/init.d/setiathome start
 * Re-caching dependency info (mtimes differ)...
 * Please setup SETI@home first by running the following commands:
 * cd /var/lib/setiathome
 * /var/lib/setiathome/setiathome -login 
3./opt/setiathome/setiathome -login
  ...
4./etc/init.d/setiathome start
Actual Results:  
setiwrapper was still running in a loop in CPU 2, setiathome process was
quitting repeatedly, generating a huge log file.

Expected Results:  
started two setiathome threads.

Portage 2.0.50-r1 (default-amd64-2004.0, gcc-3.3.3, glibc-2.3.3_pre20040207-r0,
2.6.3-gentoo)
=================================================================
System uname: 2.6.3-gentoo x86_64 5
Gentoo Base System version 1.4.3.13p1
Autoconf: sys-devel/autoconf-2.59-r3
Automake: sys-devel/automake-1.8.2
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CFLAGS="-O2"
CHOST="x86_64-pc-linux-gnu"
COMPILER="gcc3"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config
/usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d"
CXXFLAGS="-O2"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache sandbox"
GENTOO_MIRRORS="http://gentoo.ccccom.com http://gentoo.netnitco.net
http://mirror.clarkson.edu/pub/distributions/gentoo/
ftp://ftp.ussg.iu.edu/pub/linux/gentoo"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X amd64 apm arts avi berkdb crypt cups encode esd foomaticdb gdbm gif gnome
gpm gtk gtk2 imlib jpeg kde libg++ libwww mikmod motif mozilla mpeg multilib
ncurses nls oggvorbis opengl oss pam pdflib perl png python qt quicktime
readline sdl slang spell ssl tcpd truetype video_cards_rage128 xml2 xmms xv zlib"
Comment 1 SpanKY gentoo-dev 2004-03-04 03:32:30 UTC

*** This bug has been marked as a duplicate of 40120 ***