|
21)
Questions and Answers :
Unix/Linux :
Unrecoverable errors
(Message 589045)
Posted 19 Jun 2007 by Bryn Post: Debian probably has memtest installed or at least available from the distro media. It's often automatically installed and available from the initial startup boot menu. Or, if the Debian CD/DVD will boot into a 'rescue' mode (usually just a basic shell prompt) then it should be available from there too. |
|
22)
Questions and Answers :
Unix/Linux :
Boinc - Seti - nice
(Message 587254)
Posted 15 Jun 2007 by Bryn Post:
Oops, sorry - you meant 'seti' but I thought 'generally'. Thanks - it's still useful to know. |
|
23)
Questions and Answers :
Unix/Linux :
Boinc - Seti - nice
(Message 586758)
Posted 14 Jun 2007 by Bryn Post: The Linux apps for 2.6 kernel have a build in shedular /priority code wich will set them on "0" as nice level. Huh? How do you make an application dependent on a specific kernel version? Surely once any linked library version requirements have been satisfied the kernel version should be irrelevant. Or are you referring to an application which is old enough to expect only library versions as would have been provided with kernel 2.4? |
|
24)
Questions and Answers :
Unix/Linux :
Won't upload results to SETI.
(Message 575356)
Posted 25 May 2007 by Bryn Post: But what i did was installing KDE (or at least some KDE libs first). Might be that it had something to do with this No. BOINC/Seti lib requirements are pretty modest 'vanilla Linux' and aren't dependent on any GUI being installed or changed. Sorry I can't help with the rest, but from my experiences upload & download is still a little choppy after the recent problems. But... it is working. |
|
25)
Questions and Answers :
Unix/Linux :
Questions...
(Message 574843)
Posted 24 May 2007 by Bryn Post: BTW... What is a "a return value of -182"??? Haven't been able to dig that up. Google is your friend ;) See here for error list. |
|
26)
Questions and Answers :
Unix/Linux :
Bionic won't shut down
(Message 556658)
Posted 30 Apr 2007 by Bryn Post: Just to comment on this - Dotsch and Martin are spot-on here with this CPU usage issue and in many cases Windows users hit a problem with switching their understanding of resource usage from the way Redmond does it to the way Linux does it. Really, they're very different indeed. I've seen a similar thing with memory use - users worrying because all of their memory is in use when they casually check it, and often ask how to reduce the usage. The glib - but relevant - answer for both cases is "But why would you want your CPU or memory to be doing nothing at all?". Trust the OS - it knows best how to manage resources and has many tools to allow further refinement. As Martin says, the CPU task-switches blindingly fast and will happily rattle through several tasks with no perceptible slowdown for the user. One of my Seti boxes is an ancient PIII 800MHz, running SUSE 9.3 in 768MB RAM and it runs BOINC constantly 'out the box'. 'top' shows seti using around 98% CPU yet I have a couple of browser windows, a newsreader and a handful of console windows open - all chugging away with no slowdown or lockups at all. I think there has to be some hardware quirk in your system which is causing these slowdowns - especially as you had the same problem with that other OS. Oh and BTW - the "grep limit global_prefs*xml" issue from a few posts back fails because there's no space after "_prefs" ;) |
|
27)
Questions and Answers :
Unix/Linux :
run_client --attach_project
(Message 555341)
Posted 28 Apr 2007 by Bryn Post:
Yep, we're getting there... ;) The key is what's mailed to you when you join a project (I mean via the project's website, not using BOINC) and/or download its agent. The mail contains your project user name, the project URL and the account key. Here's what I was mailed for seti (edited to hide the obvious):
The key length is 32 chars for Seti, and I received a similar mail from the World Community Grid, the other project I'm running. Maybe a search of your incoming mail stash will find it, although IIRC you can generally request a reminder of this stuff - you'll likely find info about that on/near the Seti homepage. |
|
28)
Questions and Answers :
Unix/Linux :
run_client --attach_project
(Message 554938)
Posted 27 Apr 2007 by Bryn Post:
Well, this stuff isn't telepathic you know... ;) And my apologies - I missed something else in your first post: you said you're doing "run_client --attach_project" but it should be "run_client -attach_project" Just the one "-" is expected. |
|
29)
Questions and Answers :
Unix/Linux :
run_client --attach_project
(Message 554475)
Posted 26 Apr 2007 by Bryn Post:
You're providing a URL, but not the key. |
|
30)
Questions and Answers :
Unix/Linux :
Linux new install
(Message 546845)
Posted 15 Apr 2007 by Bryn Post: On SUSE (or 9.3, anyway) startup scripts go into /etc/init.d/ for better LSB compliance although there's also a link '/etc/rc.d/' which points to the same thing. Subdirectories rc3.d and rc2.d etc. can be found in there. The preferred place to set shell variables in a SUSE installation for logon shells is in ~/.profile (which will get read each time a logon shell is started), or more globally in /etc/bash.bashrc.local otherwise. The SUSE user manuals give a pretty good basic introduction to Linux, but of course there's plenty of other stuff on-line. If you have access to newsgoups, quite a friendly bunch hang out in alt.os.linux.suse |
|
31)
Questions and Answers :
Unix/Linux :
Smoothwall 2.0 kernel 2.4.33
(Message 544187)
Posted 11 Apr 2007 by Bryn Post: ./boinc: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Probably your best bet is to ask on the Smoothwall forums about the installation of this library. On a SUSE installation, this is part of the standard C++ headers & libraries package and as your earlier post said, GTK & glibc would already be included in recent Linux distributions |
|
32)
Questions and Answers :
Unix/Linux :
Smoothwall 2.0 kernel 2.4.33
(Message 543403)
Posted 9 Apr 2007 by Bryn Post: Pretty clever (and free), but for most home users doesn't really do the job any better than a good NAT router. Yep, agreed! Thanks for the links, too. Much appreciated. Looks like the OP needs to provide some more information... |
|
33)
Questions and Answers :
Unix/Linux :
Is there any working screensaver for linux/kde??
(Message 543195)
Posted 9 Apr 2007 by Bryn Post: Is it a bad thing to have? No, not at all. You wouldn't mind having one. The poster to which I replied thought it pitiful that there wasn't one. There's a big difference. But... there still isn't one. As Dotsch said, it's just something which hasn't been ported to the Linux version. Are you volunteering to add it? ;) |
|
34)
Questions and Answers :
Unix/Linux :
Smoothwall 2.0 kernel 2.4.33
(Message 543187)
Posted 9 Apr 2007 by Bryn Post: complained about missing libraries What libraries did it complain about? What is "smoothy" and "smoothwall" - Linux distributions? |
|
35)
Questions and Answers :
Unix/Linux :
Result Errors on a G4 Mac running Ubuntu 6.06
(Message 542239)
Posted 7 Apr 2007 by Bryn Post:
No, this output shows that there is no instance of boinc running - it's just showing the grep process running. When a process is started it's assigned a process ID (PID) which will increment each time, so what you're seeing is the changing PID of each 'grep' process you run. Notice the command shown at the end of that line: grep boinc That's what you appended to the 'ps' command. The '|' character says 'and send the output to the input of what follows' so really, you're chaining two commands together (or in my version, three). It's generally called the 'pipe' character in this context, because you're sending output through a pipe to another process. (think of data as running water, and each command you pipe the water to as a type of water filter or purifier) Because of the sequence in which the commands are executed (and it's not necessarily as obvious as it looks from a shell prompt) you'll end up with both 'ps' and 'grep' active at the same time, because 'ps' will be busy piping its output to grep. Because of this, 'ps' (which is just listing active processes) must include your occurrence of 'grep' in its output. Now 'ps -eaf' will produce a mass of data about all running processes which is clearly far too much, so that output is filtered by passing it (using the '|' character) to the input of grep. Because grep is being asked to match only the string 'boinc', all the other output from the earlier 'ps' part is discarded - or more accurately, all the output from 'ps -eaf' which doesn't include the string 'boinc'. If you then send the output through another filter - my third part 'grep -v grep' then you will no longer see information about the running grep process. The '-v' switch simply forces an inverted match, so that everything except the string 'grep' is matched. Since the pipe at this point will only contain data for one or more running boinc processes and the previous 'grep boinc' process - because they all contain the characters 'boinc' - this effectively just tightens the match so that only running boinc process(es) are displayed. Now since your output above only shows one running process which includes the string 'boinc', and that is actually part of the 'grep boinc' command - there is in fact no boinc process running at all. If you'd included my '| grep -v boinc' part then you would have got no output at all - indicating, even more clearly, that there is no boinc process active. Feel free to run just 'ps -eaf' (it's only displaying stuff and won't cause any damage). You should see 'bash' mentioned at least once amongst a long list of data, so now try 'ps -eaf | grep bash' and notice that you now only see data which contains the string of characters 'bash'. You should also see one occurrence of 'grep bash' which, although it references 'bash' has nothing to do with it being an actual, running occurrence of bash: it's just your grep command showing up. Finally, try 'ps -eaf | grep bash | grep -v grep' and now the misleading, apparent occurrence of bash is no longer displayed. One of the strengths of Unix/Linux is the idea of small, perfectly formed programs which perform one task very well - and that their input and output can be connected to each other through use of the pipe character '|' So here, we have one program 'ps' which is only interested in showing data about processes - being "assisted" by feeding its output into another program which is only interested in pattern matching. It's quite easy to string together several programs like this which allows quite complex data manipulation and refinement through the use of simple building blocks. Try doing that sorth of thing with a GUI-only interface... ;) (we now return you to the regular broadcast, with apologies for the momentary thread hijacking for tutorial purposes) |
|
36)
Questions and Answers :
Unix/Linux :
Result Errors on a G4 Mac running Ubuntu 6.06
(Message 541831)
Posted 6 Apr 2007 by Bryn Post:
Yes, that's all it was supposed to do - just make what's displayed specific to a running boinc process and free of any confusing information about grep. In your previous post you were trying to kill a finished grep process.
Because the process is being run by a user called 'boinc', and one user cannot normally kill another user's processes - unless he tries it as root. (apologies - I should have mentioned this earlier) First, enter: su and provide the root password. Then run ps -eaf (etc) to get the boinc PID and kill it. When that's done, enter: exit to return to your normal user prompt. |
|
37)
Questions and Answers :
Unix/Linux :
Result Errors on a G4 Mac running Ubuntu 6.06
(Message 541485)
Posted 5 Apr 2007 by Bryn Post:
You're catching the 'grep' process while it's looking to match 'boinc' and the output is giving the impression that the grep session is in fact a boinc session. That's why the process ID changes each time you run grep - because it's a new process each time, and of course it's finished running by the time you try to kill it - hence the "no such process" error. Try this instead, which won't display the active grep process: ps -eaf | grep boinc | grep -v grep |
|
38)
Questions and Answers :
Unix/Linux :
Linux/x86_64
(Message 539749)
Posted 1 Apr 2007 by Bryn Post: 40 years in computers and 15 years in Linux has actually taught me something. And evidently not enough. |
|
39)
Questions and Answers :
Unix/Linux :
Linux distro for SETI
(Message 539083)
Posted 31 Mar 2007 by Bryn Post:
Using 'ldd' will show the specifics but in order for those to be available to an application, quite a bit of Linux 'gruntwork' stuff would need to be included too. Not sure about DSL, but Knoppix has some info about customising their distribution so if there isn't a similar thing for DSL (but surely that's small enough already?), the Knoppix data should still be mostly relevant. I had a quick tinker with Debian a while ago and a "oh go on, chuck it all on there" default desktop-style install was only 1.4G. That would fit onto a USB stick yet still provide a bootable, fully-loaded point-n-drool system! |
|
40)
Questions and Answers :
Unix/Linux :
Linux distro for SETI
(Message 537983)
Posted 28 Mar 2007 by Bryn Post: I have a pile of old computers lying here - mainly P3s and I want to run BOINC on them. A PIII is fine, especially if it's just sitting there doing nothing. I run BOINC on an ancient 800MHz PIII in 768MB RAM and workunits are turned around in about 0.9 days. Not exactly scorchingly fast, but quite fast enough to be useful. |
©2020 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.