Linux problem solution found


Advanced search

Message boards : Application Info : Linux problem solution found

Sort
Author Message
Profile Andre Kerstens
Forum moderator
Project tester
Volunteer tester
Avatar

Joined: Sep 11 06
Posts: 749
ID: 1
Credit: 15,199
RAC: 0
Message 460 - Posted 19 Sep 2006 15:39:17 UTC

We have finally found the cause of the problem that some users were experiencing on their Linux systems. It has to do with the stacksize setting on your machine which is for some distros (SuSE 9.3 and 10 for example) set to unlimited and for others (FCx, Ubuntu, etc) set to a limited value like 10240. Your setting can be seen by typing 'ulimit -s' in a terminal. To make the Charmm 'exit 1' errors go away, please set the stacksize to unlimited using the command 'ulimit -s unlimited'. This is not saying that Charmm will use all of your memory (it won't), but it gives us a little bit more space to do our simulations correctly and without errors. Please let us know if this does not work for you. If it does work, please add this command to your shell initialization file (.bashrc, .tcshrc, .kshrc, etc) in your home directory. Of course don't forget to resume the D@H project on your boincmgr in case you suspended it before.
____________
D@H the greatest project in the world... a while from now!

daniele
Volunteer tester

Joined: Oct 23 06
Posts: 86
ID: 190
Credit: 6,702
RAC: 0
Message 1066 - Posted 25 Oct 2006 12:16:18 UTC
Last modified: 25 Oct 2006 12:23:19 UTC

Good work Andre, in a few days I'll complete my exams and I'll participate more intensively to the alfpha testing (for the linux client). I've a couple of ideas about creating a thread in which linux users can report the usage of resources by your application, and other useful informations.

For now all is working fine on my system. I noticed that, when resolving the amount of credits for a WU, you choose the value in the middle and assign that value to the WU. For now I have been the man in the middle three times out of three.

To help with the `ulimit` command, remember that it applies only to shell instances in which you typed it, and to the son processes. So, if you type it in a terminal and start the core client, it will have unlimited stack, and the same will be for the apps launched by the client.
But if you want the client to be started at boot time, when entering runlevel 2 (as for a daemon), you'll have to modify the init script in /etc/init.d directory, named boinc-client, with the `ulimit` command.

Look for the start() function in the script, should be something like the one below. Add the command where I did, using lowercase letters

start()
{
log_begin_msg "Starting $DESC: $NAME"
if is_running; then
log_progress_msg "already running"
else
ULIMIT -S UNLIMITED
start-stop-daemon --start --quiet --background (etc etc etc)
fi
log_end_msg 0
}

This will affect ONLY the processes created in between the execution of the ulimit command and the exit from the script (for example, if the script is called at boot time, ONLY the start-stop-daemon command will be affected (and the script itself, while it's being executed).

This way, only the core client will have such this permission (unlimited stack!), which is much safer for your system.


I'm investigating on the fact that, if you modify the file /etc/security/limits.conf by adding a row like this

boinc - stack unlimited

it doesn't work, i.e. the boinc user will not use the new permission.
It probably depends on one of these three other facts:
1) the row is wrong, i've to specify the limit as a hard (or soft, I don't know yet) one;
2) this row is used only when the boinc user starts a shell instance, and the boinc user will never do it, since in the init script this is done by root, who starts the daemon;
3) I read that this file is to be used only by PAM applications, and I don't really know if the core client is something like that.

Making this row working would be the most elegant solution :)
After managing to run the app with a plain 8 MB stack, of course.

Profile Andre Kerstens
Forum moderator
Project tester
Volunteer tester
Avatar

Joined: Sep 11 06
Posts: 749
ID: 1
Credit: 15,199
RAC: 0
Message 1073 - Posted 25 Oct 2006 15:43:54 UTC - in response to Message ID 1066 .

Hi Daniele,

Thanks for your help. Hopefully the ulimit change will only be a temporary solution. We are working to find a fix on the application side since we don't want to ask everybody to make these changes to their systems. For now we only have 70 linux users, but when we are completely live this number might go up in the thousands.

Thanks again and success with your exams,
Andre

Good work Andre, in a few days I'll complete my exams and I'll participate more intensively to the alfpha testing (for the linux client). I've a couple of ideas about creating a thread in which linux users can report the usage of resources by your application, and other useful informations.

For now all is working fine on my system. I noticed that, when resolving the amount of credits for a WU, you choose the value in the middle and assign that value to the WU. For now I have been the man in the middle three times out of three.

To help with the `ulimit` command, remember that it applies only to shell instances in which you typed it, and to the son processes. So, if you type it in a terminal and start the core client, it will have unlimited stack, and the same will be for the apps launched by the client.
But if you want the client to be started at boot time, when entering runlevel 2 (as for a daemon), you'll have to modify the init script in /etc/init.d directory, named boinc-client, with the `ulimit` command.

Look for the start() function in the script, should be something like the one below. Add the command where I did, using lowercase letters

start()
{
log_begin_msg "Starting $DESC: $NAME"
if is_running; then
log_progress_msg "already running"
else
ULIMIT -S UNLIMITED
start-stop-daemon --start --quiet --background (etc etc etc)
fi
log_end_msg 0
}

This will affect ONLY the processes created in between the execution of the ulimit command and the exit from the script (for example, if the script is called at boot time, ONLY the start-stop-daemon command will be affected (and the script itself, while it's being executed).

This way, only the core client will have such this permission (unlimited stack!), which is much safer for your system.


I'm investigating on the fact that, if you modify the file /etc/security/limits.conf by adding a row like this

boinc - stack unlimited

it doesn't work, i.e. the boinc user will not use the new permission.
It probably depends on one of these three other facts:
1) the row is wrong, i've to specify the limit as a hard (or soft, I don't know yet) one;
2) this row is used only when the boinc user starts a shell instance, and the boinc user will never do it, since in the init script this is done by root, who starts the daemon;
3) I read that this file is to be used only by PAM applications, and I don't really know if the core client is something like that.

Making this row working would be the most elegant solution :)
After managing to run the app with a plain 8 MB stack, of course.


____________
D@H the greatest project in the world... a while from now!

Message boards : Application Info : Linux problem solution found

Database Error
: The MySQL server is running with the --read-only option so it cannot execute this statement
array(3) {
  [0]=>
  array(7) {
    ["file"]=>
    string(47) "/boinc/projects/docking/html_v2/inc/db_conn.inc"
    ["line"]=>
    int(97)
    ["function"]=>
    string(8) "do_query"
    ["class"]=>
    string(6) "DbConn"
    ["object"]=>
    object(DbConn)#8 (2) {
      ["db_conn"]=>
      resource(60) of type (mysql link persistent)
      ["db_name"]=>
      string(7) "docking"
    }
    ["type"]=>
    string(2) "->"
    ["args"]=>
    array(1) {
      [0]=>
      &string(50) "update DBNAME.thread set views=views+1 where id=47"
    }
  }
  [1]=>
  array(7) {
    ["file"]=>
    string(48) "/boinc/projects/docking/html_v2/inc/forum_db.inc"
    ["line"]=>
    int(60)
    ["function"]=>
    string(6) "update"
    ["class"]=>
    string(6) "DbConn"
    ["object"]=>
    object(DbConn)#8 (2) {
      ["db_conn"]=>
      resource(60) of type (mysql link persistent)
      ["db_name"]=>
      string(7) "docking"
    }
    ["type"]=>
    string(2) "->"
    ["args"]=>
    array(3) {
      [0]=>
      object(BoincThread)#3 (16) {
        ["id"]=>
        string(2) "47"
        ["forum"]=>
        string(2) "11"
        ["owner"]=>
        string(1) "1"
        ["status"]=>
        string(1) "0"
        ["title"]=>
        string(28) "Linux problem solution found"
        ["timestamp"]=>
        string(10) "1161791034"
        ["views"]=>
        string(4) "1796"
        ["replies"]=>
        string(1) "2"
        ["activity"]=>
        string(23) "1.5874815632574998e-129"
        ["sufferers"]=>
        string(1) "0"
        ["score"]=>
        string(1) "0"
        ["votes"]=>
        string(1) "0"
        ["create_time"]=>
        string(10) "1158680357"
        ["hidden"]=>
        string(1) "0"
        ["sticky"]=>
        string(1) "0"
        ["locked"]=>
        string(1) "0"
      }
      [1]=>
      &string(6) "thread"
      [2]=>
      &string(13) "views=views+1"
    }
  }
  [2]=>
  array(7) {
    ["file"]=>
    string(63) "/boinc/projects/docking/html_v2/user/community/forum/thread.php"
    ["line"]=>
    int(184)
    ["function"]=>
    string(6) "update"
    ["class"]=>
    string(11) "BoincThread"
    ["object"]=>
    object(BoincThread)#3 (16) {
      ["id"]=>
      string(2) "47"
      ["forum"]=>
      string(2) "11"
      ["owner"]=>
      string(1) "1"
      ["status"]=>
      string(1) "0"
      ["title"]=>
      string(28) "Linux problem solution found"
      ["timestamp"]=>
      string(10) "1161791034"
      ["views"]=>
      string(4) "1796"
      ["replies"]=>
      string(1) "2"
      ["activity"]=>
      string(23) "1.5874815632574998e-129"
      ["sufferers"]=>
      string(1) "0"
      ["score"]=>
      string(1) "0"
      ["votes"]=>
      string(1) "0"
      ["create_time"]=>
      string(10) "1158680357"
      ["hidden"]=>
      string(1) "0"
      ["sticky"]=>
      string(1) "0"
      ["locked"]=>
      string(1) "0"
    }
    ["type"]=>
    string(2) "->"
    ["args"]=>
    array(1) {
      [0]=>
      &string(13) "views=views+1"
    }
  }
}
query: update docking.thread set views=views+1 where id=47