I merged setiathome supposedly successfully. I think that the files came from the University of Wisconsin but I am not sure. But, then, setiathome would not start. Reproducible: Always Steps to Reproduce: 1. Tried /etc/init.d/setiathome start [or stop] 2. Tried rebooting 3. Actual Results: An error message appeared in setiathome.log. setiathome did not start. Expected Results: Start setiathome The cause of the error appears to be two lines, both containing the word setiwrapper, in the file that becomes /etc/init.d/setiathome. A search of the web implies that setiwrapper is used only on Windows NT systems. I edited the first of these lines, which starts setiathome, so that it executes /opt/setiathome/setiathome. Note that this command must be executed from the /var/lib/setiathome directory, which is where the seti data is. I deleted the second line. Now seti works as expected.
the wrapper was added to the portage package by myself
Any chance of this showing up in stable any time soon?
ah, i see where i screwed up ... i updated the 3.03-r1 ebuild to fix non-x86 arches but as a result i broke the 3.08-r1 ebuild ... i'll have this fixed up soon and probably release 3.08-r2
*** Bug 41737 has been marked as a duplicate of this bug. ***
Created attachment 26049 [details] corrected init.d - script. There was an error, when the script wanted to start the application. Put the new one in and it will function. Much fun!
There is a problem with Mr. P's /etc/init.d/setiathome script. The ebuild script puts the setiathome executable in the /opt/setiathome directory, not in the SETIATHOME_DIR directory, which is usually /var/lib/setiathome. The latter contains the datafiles. There is one other potential difficulty. If you start setiathome at boot, the user will normally be root. However, the user of a setiathome control program such as tkseti is normally a user other than root; it is "ivar" in my case. Hence, the control package to do some things like kill the running setiathome. My solution is a line like the following in the /etc/init.d/setiathome script: su ivar -c 'cd /var/lib/setiathome; /opt/setiathome/setiathome -graphics -nice 19 >& setiathome.log &' Of course, you have to substitute your own user name for ivar.
I mangled one sentence. I should have said: Hence, the control package can't do some things like kill the running setiathome.
*** Bug 43642 has been marked as a duplicate of this bug. ***
Hello SpanKY, I opened bug 43642 because the original description for this bug didn't seem to cover the problems I described at all. Are you sure they are related ?
in general i screwed up the init script for 3.08 while fixing 3.03 the init script needs to be rewritten ... most of your troubles are because of the threading stuff which is broken
Ok, SpanKY, thanks for your effort!
*** Bug 43846 has been marked as a duplicate of this bug. ***
does setiathome-3.08-r2 address these (and any other) issues you guys had ?
Setiathome will start now when installed using setiathome-3.08-r2. However, I still had to modify the setiathome file in /etc/init.d so that the setiathome process will be owned by me and not by root when setiathome is started at bootup. I also had to modify the permissions in the /var/lib/setiathome directory.
If the binary is under /opt then surely the data files should be under /var/opt not /var/lib http://www.pathname.com/fhs/pub/fhs-2.3.html#VAROPTVARIABLEDATAFOROPT states "Variable data of the packages in /opt must be installed in /var/opt/<subdir>"
This problem still exists. I just tried the new setiathome, and am running into the same problems. I suspect the the setiwrapper script is at fault. ps shows two instances of setiwrapper running and only one setiathome. one instance of setiwrapper is taking up 100% of one CPU, while the other is taking up 0. The setiathome that is runnng is taking up all of the other cpu.
Created attachment 29823 [details] init.d script for using seti user & group, plus also fix for stopping bug
Created attachment 29824 [details] Updated setiwrapper script for running binary as seti user
In my opinion the script is still broken anyway, twice over! 1) "/etc/init.d/setiathome stop" will not work properly for people using the setiwrapper, and will require the use of "/etc/init.d/setiathome zap" to manually kill-off the "running" state of the service for a user to ever be able to restart the script with "/etc/init.d/setiathome start" This is because the lines in /etc/init.d/setiathome that presently read... " stop() { ebegin "Stopping SETI@home" killall setiwrapper killall setiathome eend $? } " ...will cause a failure return code everytime, because although killing setiwrapper will succeed, killing setiathome will not! In my opinion the script here ought to read... " stop() { ebegin "Stopping SETI@home" killall setiwrapper || killall setiathome eend $? } " ...such that "killall setiathome" only gets run if "killall setiwrapper" failed. See updated script attached. 2) Others have commented here how running seti@home as root prevents them from getting at the stats from user-space programs. Much more serious than that is that the script is running a *3RD PARTY BINARY* as *ROOT* totally *UNNECESSARILY*. To run a service as root that doesn't need to be doing so is generally depreciated, but to be doing so with a binary where the source is unavailable is daft. In my opinion, and I'm sure others will agree, the present config is an unnecessary potential security risk (more from the risk of the binary crashing and going bezerk and hurting anything it likes given that it is presently root!) Could the ebuild not simply create seti user and group, and instead within setiwrapper use "su seti -c" to run setiathome binary, and "chown seti.seti" the directories and relevant files within "/etc/init.d/setiathome)? This is how I currently have setiathome configured, this has the advantage of running seti as an otherwise totally unprivilidged user, with the binary totally unable to do any damage should it crash or have been compromised... ...and ALSO has the advantage that any users who want to get at the statistics with things like ksetispy (or whatever it is called) can just simply get themselves added to the seti group? Again, see the attachments. I have to say, without wishing to seem rude, I'm uncomfortable that this and the previous seti ebuilds are considered a stable release. *8-/ Ta-ra, Julie http://www.computergeeks.co.uk/
Created attachment 29835 [details] init.d script for using seti user & group, plus also fix for stopping bug Ooops, the previous version of the script didn't work as expected, sorry, doh... this version should neatly manually kill the setiwrappers and associated children processes
Created attachment 29836 [details] setiwrapper for running setiathome as seti user, and also delaying between invocations Previous version left in the apparently non-sensical "wait $?" command (ummmm... wait until the process with the same number as the previous return-code exits?) Runs setiathome as a "seti" user for security purposes. Also this version does a manual wait of one hour, before respawning setiathome -- in keeping with seti@home policy (not supposed to respawn without a delay... let's not get gentoo users into seti@homes bad books eh! ;-)
This bug is getting rather messy. Shouldn't different bug reports be filed on the different problems? Or should we expect a brand new working version of setup and init scripts, placing data files in /var/opt, running setiathome as an unprivileged seti user, and actually working with multiple processes? I was rather surprised to find a "stable" setup script that pretends to do things that actually don't work. If you know there are problems, why not just remove the parts that don't work, and stick with a very simple script that at least doesn't pretend to do anything fancy? No offense, but this is not a viable solution, and it seems it has been this way for a long time. Anyway, I ended up here because I had the same problem running multiple instances as Marius Caldas. I found a very simple solution: Prevent /var/lib/setiathome/setiwrapper from changing directory! Ie. remove the line cd $(dirname $0) from the small script! /etc/init.d/setiathome does the job of changing directories anyway...
Created attachment 30443 [details] init.d script for using seti user & group, plus also fix for stopping bug subtle bug fix, su will now correctly give the seti bin its appropriate extra command line options (e.g. nice -19)
Created attachment 30445 [details] setiwrapper for running setiathome as seti user, and also delaying between invocations subtle bug fix, su should now correctly give the seti bin its appropriate extra command line options (e.g. nice -19)
Good one Julie
The user of setiathome is still root in the latest version of Gentoo setiathome. Hence, the seti gui programs such as Tk-SETI can monitor the progress of setiathome but cannot change it, e.g., they can't kill or pause or run it. Ivar
This has languished for a long time, probably longer than it should have. As version 3 is now obsolete and I have committed the boinc based version 4 client to the portage tree I would appreciate you testing these. They use the boinc user and group and are hopefully much improved. I am closing this bug, but please open new bugs for any issues you encounter with the new setiathome client. The old ebuilds will be removed in due course as the clients no longer work and the SRC_URI is invalid. I can also be found in #gentoo-science if you would like to discuss the new setiathome ebuilds.
