have successfully run on this machine before, now has downloaded the new sulfur version, and now complains that there is no libX11.so - sure there isn\'t - that\'s a firewall computer, and no plans to install X11 jsut for the climateprediction.net client.

Has anyone else experienced that? Am I the only one running the client on a very small linux?

Here\'s the error from my result file, result ID:1339602:
<core_client_version>5.2.4</core_client_version>
<stderr_txt>
dlopen() failed: libX11.so.6: cannot open shared object file: No such file or directory
No graphics.

</stderr_txt>
<message><file_xfer_error>
<file_name>sulphur_e8em_000664078_0_1.zip</file_name>
<error_code>-161</error_code>
<error_message></error_message>
</file_xfer_error>


Anyone that can help?

Cpdn is moving into the next phase of the project, and the latest software needs the file.
If that computer doesn\'t have it, and you don\'t intend putting it on that computer, then don\'t run cpdn on it.
The other projects may have lesser requirements.

Cpdn is moving into the next phase of the project, and the latest software needs the file.
If that computer doesn\'t have it, and you don\'t intend putting it on that computer, then don\'t run cpdn on it.
The other projects may have lesser requirements.

For what does it need this file?

---

Linux Users Everywhere @ BOINC

I think this type of file/filename was mentioned some time ago as being part of the latest compiler used at the project.
If it IS/WAS this, the previous posts were about users having an older version, which was causing errors.

But I\'m not a Linux person, so I don\'t know it\'s exact use.

Bernhard : I\'ll tale a look at this.
The main program only tries to launch the graphics thread
if the libraries are available and dlopen succeeds.
If this fails, then it assumes the prerequisite graphics
libraries aren\'t available and continues to launch the worker
program.

---

hi Bernhard

I am running several linux & windows boxes and sulphur seems unhappy on linux. I am using Debian & CentOS so whatever the issue is it is not about IPcop

Like you I one of my clients is on a very small linux, but the problem seems there on all the linux boxes - the speed ratio between hadsM3 model and sulphur is much worse than on my windows boxes. None of my linux sulhur models have trickled despite the hadsM3 models on other machines doing a few trickles in the same period, and I am getting concerned.

I get these messages in the BOINC standard output as the sulphur model starts up:

Created shared memory region key = 77230 of size 569976 bytes
Can\'t setup pointer to .so shared memory sulphur_4.22_i686-pc-linux-gnu:
undefined symbol: setupSharedMem!
Can\'t setup pointer to .so graphics cleanup sulphur_4.22_i686-pc-linux-gnu:
undefined symbol: graphics_thread_cleanup

are these related to the same issue?

Bernhard you quoted some info from your results file, where do I find the results file please?

apols if this is off topic, I am not sure if I am seeing the same problem or a different one. I have set nomorework on all my linux boxes to make sure I don\'t get any more sulphur models, and I am wondering if I should detach all my linux boxes as soon as they run out of hadsM3 work...

Thanks

---

...
The main program only tries to launch the graphics thread
if the libraries are available and dlopen succeeds.
...

hi Tolu,

I have just noticed an interesting difference between the hadSM3 and sulphur WU. You can use ./boinc_cmd --get_state or --get_results to see it.

The slab result is shown as not supporting graphics, but the sulphur result claims it does support graphics. (Last item output for each result). I have just seen this on a CentOS linux twin cpu box that is running one of each model at present - maybe both the results should show the same value on the same box, especially as both are currenltly running
.
The following comes from a --get_status on this box at about 2000 UTC 07-dec-2005

======== Results ========
1) -----------
[einstein wu here]
6) -----------
name: 15iw_300074376_1
WU name: 15iw_300074376
project URL: http://climateprediction.net/
report deadline: Sat Oct 28 09:49:27 2006
ready to report: no
got server ack: no
final CPU time: 376737.550000
state: 2
scheduler state: 2
exit_status: 0
signal: 0
suspended via GUI: no
aborted via GUI: no
active_task_state: 1
stderr_out:
app version num: 413
checkpoint CPU time: 507221.090000
current CPU time: 508314.840000
fraction done: 0.262679
VM usage: 0.000000
resident set size: 0.000000
estimated CPU time remaining: 4480409.668336
supports graphics: no
7) -----------
name: sulphur_ad7y_000483694_0
WU name: sulphur_ad7y_000483694
project URL: http://climateprediction.net/
report deadline: Sat Oct 28 09:49:37 2006
ready to report: no
got server ack: no
final CPU time: 0.000000
state: 2
scheduler state: 2
exit_status: 0
signal: 0
suspended via GUI: no
aborted via GUI: no
active_task_state: 1
stderr_out:
app version num: 421
checkpoint CPU time: 82556.070000
current CPU time: 85259.030000
fraction done: 0.002868
VM usage: 0.000000
resident set size: 0.000000
estimated CPU time remaining: 17605569.873777
supports graphics: yes

hope this is a useful clue

---

River: I\'m assuming the sulphur and slab WU\'s are still running
( recent active trickle). If this is the case then please don\'t
detach from the project.

The problem seems to be the graphics thread.
dlopen() won\'t always succeed on every host ( several reasons e.g missing libX11.so.6 or one of the other X libs ).
This is why the graphics thread is implemented as a
shared library and outside of the main program.

So if it fails, no biggie - you can continue running as normal.
but you won\'t be able to launch the graphics program.

Is anyone else having this problem of crash WU because of missing
X libs? is this behaviour repetitive?

---

River: I\'m assuming the sulphur and slab WU\'s are still running
( recent active trickle). If this is the case then please don\'t
detach from the project.

on this machine A yes, both are still running and the slab is trickling -- no trickles from sulphur as yet.

These other five linux boxes B C D E F all had sulphur WU that never trickled after several days of working, and did not seem to be making any other signs of progress.

My seventh linux box, G is currenlty crunching a slab quite happily.

I am certainly not going to detach any box while it has working wu, but current plan is to leave nomorework set on my linux boxes and detach as the slab results come to an end.

This is partly because of this issue, and partly because of the speed issue I mentioned in this number crunching thread.

---

...The problem seems to be the graphics thread.
dlopen() won\'t always succeed on every host ...
This is why the graphics thread is implemented as a
shared library and outside of the main program.

So if it fails, no biggie - you can continue running as normal.
...

so why does the sulpur wu continue to claim it can cope with graphics, whereas the slab wu honestly admits it can\'t? (as shown in the output from --get_results)

My guess, not knowing your code but from 25yrs programming experience, is that there is a missing/faulty test in the sulphur code and my hunch is that this difference could occasionally lead to a problem for sulphur on machines without graphics support.

...but you won\'t be able to launch the graphics program.
...

just as well, like Bernhard my linux boxes are all classic unix command line only. Unless you want to write an ascii-art graphics module ;-)

---

Hello,
from all the updates that have tried to help me, I get the understanding that we are talking about different things:

When I said that it doesn\'t work for me, I meant that checking after about 24 hours for the downloaded result, I see \"Client Error\". When connecting to climateprediction.net, that result disappears.

When checking on the web page for my computer, there in the \"results\" I see state: Client Error - finished. All I can do is download a new result file and try that.

Other updates sugggest that for them, the are also getting the libX11.so missing, but it seems to continue for them.

Anyone that can verify this? Is it really aborting after that long time? The error in the log for that result shows that \"libX11.so missing\", unsure if there could be multiple errors, which I cannot check.

Regards,
Bernhard

---