That doesn't help, Mike, as it's an application error. His latest was exit with code 4, which is in my FAQs. I did email Bernd about it already as he wants to know.
Dirk, I see you're still running BOINC 5.4.11
Have you ever thought of upgrading? We are at 6.10.56 at this time...
Humbly, I withdraw my flawed reply ..... :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Dirk, I see you're still running BOINC 5.4.11
Have you ever thought of upgrading? We are at 6.10.56 at this time...
I have given it thought. But my thoughts so far tell me, that there is a greater issue than just the program files. In my past experiences with Linux, it was possible to install software generically, be that from source or sometimes otherwise. But then the follow-on subject becomes, that I'd want to configure this program to run in the correct directories, as the right user, with appropriate settings, etc.. And while even that is doable, that aspect of upgrading goes beyond my time limits, really.
Because my current package was configured for me, and for Debian/Etch, this means that everything is also installed into the appropriate directory, that the server-start entries in /etc/init.d have been written well for my setup and all that...
Also, every time I do a custom compile, I allow programs to install software, which are more overseeable than a binary install. I see every binary install off a Web site as a potential security threat, and would actually prefer to custom-compile if it ever came to that...
It might come to that on a winter weekend when the sun isn't shining bright outside...
Dirk
P.S. Mainly, I have in the past attempted to install a Debian package, only to find that my old Etch-based system is missing one or more package dependencies. Hence, a custom compile would make more sense. And then, while I've sometimes copied a file in the /etc/init.d/ directory to .bak , IF I simply decided to try running the new program from the same, old server-start script, I have no guarantee that the new program version will interpret its command-line parameters the same way my current one does. After all, an updated program is likely to have features which require my proper attention.
I ask this as not only is the Einstein application build with some of the later BOINC 6 source code, but there have been a lot of fixes going into the BOINC code between your version and the one that's the latest (and most stable of the 6 range). Amongst them many memory-related fixes, which could cure your SIGSEGV errors.
On my SuSE Linux 11.1 I have always used the Berkeley Installer package and it works on 6 projects. On a virtual machine running Solaris as a guest OS via VirtualBox I installed both BOINC 6.2.19 and setiathome 6.03 manually, getting them from a developer called Dotsch. It was an interesting exercise.
Tullio
1) Checking my package manager is something which I do every day, but Debian Etch differs from Debian/Sid, in that by now there are very few upgrades committed to this repository. One reason for which the package is usually frozen, is actually the fact that higher binaries link to dependencies which are not met in the Etch framework. So there's more than one reason for which the code gets held back in non-Sid, /Stable Debian versions. Another reason for which the code gets held back, is to give some developers the chance to develop bug fixes, instead of just adding new features to each package version. And yet, we see that many opportunities are lost just to fix bugs, because the package maintainers are a different group of people from the software developers. So maintainers do this for more critical packages, and packages such as boinc-client never receive that suffix ...5.4.11-etch1 , which would mean that an Etch stability fix has been introduces to version 5.4.11 of BOINC.
2) I don't tend to trust these arbitrary shell scripts which do an install. I know that there are nice software tools such as the 'makeself' package, and have on rare occasions used those. But my dislike for this method of installing goes beyond security. It has also happened to me (with other packages than BOINC...) that I've simply installed the binary, and that the binary was not able to link to some library files it needed. This comes back to suggest that maybe there's a reason somewhere, for which the Etch maintainers don't include higher BOINC versions, or higher versions of many programs, in their repository.
I suppose that it's somewhat remarkable then in the first place, that by doing a custom compile, I've been able to go one version higher than the package maintainers did, with other forms of software (since I run into this issue often due to Etch). I suppose that my patience can be greater than that of a typical Etch maintainer, in trying to get the highest version of something to compile.
But this also means, that instead of compiling BOINC v6.10.56, I may need to settle for compiling a slightly lower version anyway.
Which are all reasons to put on a jar of coffee before really proceeding on such a project...
I can tell you exactly what the Berkeley installer does. It's not so much an installer. It doesn't touch anything in your system. It's not like a deb or a rpm in that regards. It simply unpacks itself to where ever you put it. Here's a `ls` of the directory it creates.
Here's what I would do to test and see if it's an interaction between E@H and BOINC.
1. Shut down the core client/manager of your installed package. It should be something like `/etc/init.d/boinc/stop`.
2. Download and unpack the latest build of BOINC.
3. cd to the BOINC directory and do ./run_manager. This will start the manager and core client. Attach to E@H and let it run. Don't close the manager as that'll shut down the client too.
4. See if it crashes. If it does, then we've ruled out the core client as an issue.
I can't be of much more assistance than this. I'm not a programmer by trade (rather an English teacher). I know what I know from basically breaking things...
This is clearly a big surprise to me. What I'm more used to, is having to put symlinks to my shared libraries, because a program was compiled to look for them in some slightly different directories from where I have them installed... And of course, the main advantage of a custom compile is that the configuration script finds all the correct libraries. But then again, maybe BOINC doesn't depend on so many of them? It's only a weaker advantage, that the executable has been compiled using header files which exactly match the installed shared libraries, because there is supposed to be run-time compatibility.
And so I'll take you up on that idea.
I guess then, that this shell script does a user-space install... I never knew that. I always suspected that I'm being asked to run a shell script in root mode...
Edit: Ahh... but here is the message that I get next:
./boincmgr: /lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by ./boincmgr)
This message makes perfect sense, because I'm only based on GLIBC 2.2 . Okay, so there's a dependency issue even with such a simple script. But now, this may or may not mean, that I'd fail even to compile the latest version. I'll find out when I have time...
When I try to configure the compilation of 6.10.56.orig, this is the message that I get:
checking for gawk... (cached) gawk
checking for curl-config... /usr/bin/curl-config
checking for the version of libcurl... 7.15.5
checking for libcurl >= version 7.17.1... no
configure: error:
================================================================================
ERROR: could not find (recent enough) development-libs for libcurl.
This library is required to build the boinc-client.
(If you don't want to build the client, use --disable-client with configure.
If libcurl-dev is installed on your system, make sure that the script
'curl-config' is found in your PATH, and that
'curl-config --version' gives something recent enough (see above).
And look what happens, when I try to download an earlier tarball:
user@Thunderbox:~/Desktop/My_Programs/boinc/pkg-boinc$ ls
branches README scripts tags trunk
user@Thunderbox:~/Desktop/My_Programs/boinc/pkg-boinc$ ./scripts/export-boinc -r 6.4.5+dfsg-3
svn export http://boinc.berkeley.edu/svn/tags/boinc_core_release_6_4_5+dfsg-3 boinc-6.4.5+dfsg-3.orig
Export complete.
find: boinc-6.4.5+dfsg-3.orig: No such file or directory
Warning: no suitable destination directory for the tarball found
Preparing source tarball as './boinc_6.4.5+dfsg-3.orig.tar.gz'.
tar: boinc-6.4.5+dfsg-3.orig: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors
user@Thunderbox:~/Desktop/My_Programs/boinc/pkg-boinc$
I got the same error message for every other version of BOINC which I tried to download. So it would seem that you guys have a *virtual* subversion repository.
And then, by lengthy trial-and-error, I also discovered that while version 5.4.11 comes through the package managers, the highest version of BOINC which I'd ever be able to compile for Etch, is 5.8.17 .
This requires --enable-unicode, because the wxWidgets libraries are unicode-based, without which wxWidgets versions aren't recognized.
However, when attempting to compile this in fact, I eventually ran into this error during make:
make[2]: Entering directory `/home/user/Desktop/My_Programs/boinc-5.8.17.orig/sea'
make[2]: *** No rule to make target `../curl/ca-bundle.crt', needed by `BOINC/ca-bundle.crt'. Stop.
make[2]: Leaving directory `/home/user/Desktop/My_Programs/boinc-5.8.17.orig/sea'
make[1]: *** [all-recursive] Error 1
Can somebody explain to me, how to try fixing this? Because on the Web, what I found was that this issue was resolved in version 6.3.x . What did people do before version 6.3.x ?
RE: That doesn't help,
)
Humbly, I withdraw my flawed reply ..... :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: Dirk, I see you're
)
I have given it thought. But my thoughts so far tell me, that there is a greater issue than just the program files. In my past experiences with Linux, it was possible to install software generically, be that from source or sometimes otherwise. But then the follow-on subject becomes, that I'd want to configure this program to run in the correct directories, as the right user, with appropriate settings, etc.. And while even that is doable, that aspect of upgrading goes beyond my time limits, really.
Because my current package was configured for me, and for Debian/Etch, this means that everything is also installed into the appropriate directory, that the server-start entries in /etc/init.d have been written well for my setup and all that...
Also, every time I do a custom compile, I allow programs to install software, which are more overseeable than a binary install. I see every binary install off a Web site as a potential security threat, and would actually prefer to custom-compile if it ever came to that...
It might come to that on a winter weekend when the sun isn't shining bright outside...
Dirk
P.S. Mainly, I have in the past attempted to install a Debian package, only to find that my old Etch-based system is missing one or more package dependencies. Hence, a custom compile would make more sense. And then, while I've sometimes copied a file in the /etc/init.d/ directory to .bak , IF I simply decided to try running the new program from the same, old server-start script, I have no guarantee that the new program version will interpret its command-line parameters the same way my current one does. After all, an updated program is likely to have features which require my proper attention.
(Sorry to bump) What I
)
(Sorry to bump)
What I just did tonight, was to check out the SVN tree, and then to check out the boinc-6.10.56.orig tarball, to decompress the tarball...
I'll take a serious look at the source code on Saturday, which is when I'll have time.
Downside: Potentially having to uninstall several boinc-packages.
Upside: Gaining the potential advantage, of the core client not shutting down, just because one work unit exits with an application error.
Another upside: Perhaps being able to run more up-to-date projects in the future...
Why build from source and not
)
Why build from source and not use the Berkeley installer package or check what's the latest available from your package manager?
Then see Installing BOINC on Debian for help.
I ask this as not only is the Einstein application build with some of the later BOINC 6 source code, but there have been a lot of fixes going into the BOINC code between your version and the one that's the latest (and most stable of the 6 range). Amongst them many memory-related fixes, which could cure your SIGSEGV errors.
Saturday is soon enough. :-)
On my SuSE Linux 11.1 I have
)
On my SuSE Linux 11.1 I have always used the Berkeley Installer package and it works on 6 projects. On a virtual machine running Solaris as a guest OS via VirtualBox I installed both BOINC 6.2.19 and setiathome 6.03 manually, getting them from a developer called Dotsch. It was an interesting exercise.
Tullio
1) Checking my package
)
1) Checking my package manager is something which I do every day, but Debian Etch differs from Debian/Sid, in that by now there are very few upgrades committed to this repository. One reason for which the package is usually frozen, is actually the fact that higher binaries link to dependencies which are not met in the Etch framework. So there's more than one reason for which the code gets held back in non-Sid, /Stable Debian versions. Another reason for which the code gets held back, is to give some developers the chance to develop bug fixes, instead of just adding new features to each package version. And yet, we see that many opportunities are lost just to fix bugs, because the package maintainers are a different group of people from the software developers. So maintainers do this for more critical packages, and packages such as boinc-client never receive that suffix ...5.4.11-etch1 , which would mean that an Etch stability fix has been introduces to version 5.4.11 of BOINC.
2) I don't tend to trust these arbitrary shell scripts which do an install. I know that there are nice software tools such as the 'makeself' package, and have on rare occasions used those. But my dislike for this method of installing goes beyond security. It has also happened to me (with other packages than BOINC...) that I've simply installed the binary, and that the binary was not able to link to some library files it needed. This comes back to suggest that maybe there's a reason somewhere, for which the Etch maintainers don't include higher BOINC versions, or higher versions of many programs, in their repository.
I suppose that it's somewhat remarkable then in the first place, that by doing a custom compile, I've been able to go one version higher than the package maintainers did, with other forms of software (since I run into this issue often due to Etch). I suppose that my patience can be greater than that of a typical Etch maintainer, in trying to get the highest version of something to compile.
But this also means, that instead of compiling BOINC v6.10.56, I may need to settle for compiling a slightly lower version anyway.
Which are all reasons to put on a jar of coffee before really proceeding on such a project...
I can tell you exactly what
)
I can tell you exactly what the Berkeley installer does. It's not so much an installer. It doesn't touch anything in your system. It's not like a deb or a rpm in that regards. It simply unpacks itself to where ever you put it. Here's a `ls` of the directory it creates.
Here's what I would do to test and see if it's an interaction between E@H and BOINC.
1. Shut down the core client/manager of your installed package. It should be something like `/etc/init.d/boinc/stop`.
2. Download and unpack the latest build of BOINC.
3. cd to the BOINC directory and do ./run_manager. This will start the manager and core client. Attach to E@H and let it run. Don't close the manager as that'll shut down the client too.
4. See if it crashes. If it does, then we've ruled out the core client as an issue.
I can't be of much more assistance than this. I'm not a programmer by trade (rather an English teacher). I know what I know from basically breaking things...
Kathryn :o)
Einstein@Home Moderator
This is clearly a big
)
This is clearly a big surprise to me. What I'm more used to, is having to put symlinks to my shared libraries, because a program was compiled to look for them in some slightly different directories from where I have them installed... And of course, the main advantage of a custom compile is that the configuration script finds all the correct libraries. But then again, maybe BOINC doesn't depend on so many of them? It's only a weaker advantage, that the executable has been compiled using header files which exactly match the installed shared libraries, because there is supposed to be run-time compatibility.
And so I'll take you up on that idea.
I guess then, that this shell script does a user-space install... I never knew that. I always suspected that I'm being asked to run a shell script in root mode...
Edit: Ahh... but here is the message that I get next:
./boincmgr: /lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by ./boincmgr)
This message makes perfect sense, because I'm only based on GLIBC 2.2 . Okay, so there's a dependency issue even with such a simple script. But now, this may or may not mean, that I'd fail even to compile the latest version. I'll find out when I have time...
When I try to configure the compilation of 6.10.56.orig, this is the message that I get:
checking for gawk... (cached) gawk
checking for curl-config... /usr/bin/curl-config
checking for the version of libcurl... 7.15.5
checking for libcurl >= version 7.17.1... no
configure: error:
================================================================================
ERROR: could not find (recent enough) development-libs for libcurl.
This library is required to build the boinc-client.
(If you don't want to build the client, use --disable-client with configure.
If libcurl-dev is installed on your system, make sure that the script
'curl-config' is found in your PATH, and that
'curl-config --version' gives something recent enough (see above).
You can download libcurl from: http://curl.haxx.se/
================================================================================
And look what happens, when I try to download an earlier tarball:
user@Thunderbox:~/Desktop/My_Programs/boinc/pkg-boinc$ ls
branches README scripts tags trunk
user@Thunderbox:~/Desktop/My_Programs/boinc/pkg-boinc$ ./scripts/export-boinc -r 6.4.5+dfsg-3
svn export http://boinc.berkeley.edu/svn/tags/boinc_core_release_6_4_5+dfsg-3 boinc-6.4.5+dfsg-3.orig
Export complete.
find: boinc-6.4.5+dfsg-3.orig: No such file or directory
Warning: no suitable destination directory for the tarball found
Preparing source tarball as './boinc_6.4.5+dfsg-3.orig.tar.gz'.
tar: boinc-6.4.5+dfsg-3.orig: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors
user@Thunderbox:~/Desktop/My_Programs/boinc/pkg-boinc$
I got the same error message for every other version of BOINC which I tried to download. So it would seem that you guys have a *virtual* subversion repository.
I eventually found the
)
I eventually found the version naming system.
And then, by lengthy trial-and-error, I also discovered that while version 5.4.11 comes through the package managers, the highest version of BOINC which I'd ever be able to compile for Etch, is 5.8.17 .
This requires --enable-unicode, because the wxWidgets libraries are unicode-based, without which wxWidgets versions aren't recognized.
However, when attempting to compile this in fact, I eventually ran into this error during make:
make[2]: Entering directory `/home/user/Desktop/My_Programs/boinc-5.8.17.orig/sea'
make[2]: *** No rule to make target `../curl/ca-bundle.crt', needed by `BOINC/ca-bundle.crt'. Stop.
make[2]: Leaving directory `/home/user/Desktop/My_Programs/boinc-5.8.17.orig/sea'
make[1]: *** [all-recursive] Error 1
Can somebody explain to me, how to try fixing this? Because on the Web, what I found was that this issue was resolved in version 6.3.x . What did people do before version 6.3.x ?
Honestly Dirk, your problems
)
Honestly Dirk, your problems are above my skill level. Can you use boinc-cmd (or what etch is calling it) to detach from E@H?
Kathryn :o)
Einstein@Home Moderator