Howto: Dealing With 0x1 Error

Hello,

the information about 0x1 error (Incorrect function) doesn't seems to be widely known for linux crunchers (especially newcomers), and there come to appear several results which were canceled with "Too many error results". It shouldn't be expected for both participants and developers side, therefore, I'll notice 0x1 error and let you know how to avoid the issue of Charmm 5.02 for linux.

At first please have a read over the FAQ, and you'll got column named "I have been receiving a message on my Linux machine where charm exits with code 1. Is there a fix to this problem?" The answer says everything needed, but it may be difficult for you to got it, so I'll paste howto written by conan, one of the hard crunchers who've joined this project from the start.

The solution to your problem, and to nearly all testers using Linux on this project has been to

1) Stop Boinc

2) Add the line " ulimit -s unlimited " (without the " marks), as the first line in the 'run_manager' file in Boinc folder.

3) Restart Boinc

If you have a dual processor then you should also add the same line to 'run_client' file in the Boinc folder as well. Also if a dual core then you may also need to reboot (as I needed to with a dual core Opteron).

Thanks Suguru,

Only one remark: we can't garantee that the memory issue will be solved in the next release, since we haven't arrived at the point of finding an app-based solution yet.

Thanks

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

Thanks for letting us know the point, Andre:)

Since there are so many cases without that process, could you notice this topic on the top page, in the column of News? There are probably users who haven't noticed on this point.

I'm afraid that thousands(!) of workunits are / will be wasted with this issue...:(

thanks,
suguruhirahara

Thanks for letting us know the point, Andre:)

Since there are so many cases without that process, could you notice this topic on the top page, in the column of News? There are probably users who haven't noticed on this point.

I'm afraid that thousands(!) of workunits are / will be wasted with this issue...:(

thanks,
suguruhirahara

Done. People should look at the FAQ too where this issue is mentioned.

Andre

Thanks for letting us know the point, Andre:)

Since there are so many cases without that process, could you notice this topic on the top page, in the column of News? There are probably users who haven't noticed on this point.

I'm afraid that thousands(!) of workunits are / will be wasted with this issue...:(

thanks,
suguruhirahara

On Ubuntu you have to add the command in the "run_manager" file, simply entering it in the terminal doesn't fix the problem.

On Ubuntu you have to add the command in the "run_manager" file, simply entering it in the terminal doesn't fix the problem.

I understand that that is only necessary for multi-core/processor machines.

AK

Shouldn't you also put it in the "run_client" file?

I understand that that is only necessary for multi-core/processor machines.

AK

Shouldn't you also put it in the "run_client" file?

On Ubuntu you have to add the command in the "run_manager" file, simply entering it in the terminal doesn't fix the problem.

Shouldn't you also put it in the "run_client" file?

On Ubuntu you have to add the command in the "run_manager" file, simply entering it in the terminal doesn't fix the problem.

Shouldn't you also put it in the "run_client" file?

It depends on how you start the client. If you only use one way then that is the only one you need to modify. I have only changed the "run_client" file since the client is already running whenever I use the manager.

Because i didnt find it in these threads.

For people using (K)Ubuntu 6.10 (and 6.06.1 as well i think) and have used the boinc from the universe repositories for their install.

The file you need to modify is found at
/etc/init.d/boinc-client not in the boinc folder as mentioned here
____________

Thanks for that info! (I've added it to the FAQ too)

AK

Because i didnt find it in these threads.

For people using (K)Ubuntu 6.10 (and 6.06.1 as well i think) and have used the boinc from the universe repositories for their install.

The file you need to modify is found at
/etc/init.d/boinc-client not in the boinc folder as mentioned here

I think this applies to most if not all debian systems.
____________

Hello,

the information about 0x1 error (Incorrect function) doesn't seems to be widely known for linux crunchers (especially newcomers), and there come to appear several results which were canceled with "Too many error results". It shouldn't be expected for both participants and developers side, therefore, I'll notice 0x1 error and let you know how to avoid the issue of Charmm 5.02 for linux.

At first please have a read over the FAQ, and you'll got column named "I have been receiving a message on my Linux machine where charm exits with code 1. Is there a fix to this problem?" The answer says everything needed, but it may be difficult for you to got it, so I'll paste howto written by conan, one of the hard crunchers who've joined this project from the start.

The solution to your problem, and to nearly all testers using Linux on this project has been to

1) Stop Boinc

2) Add the line " ulimit -s unlimited " (without the " marks), as the first line in the 'run_manager' file in Boinc folder.

3) Restart Boinc

If you have a dual processor then you should also add the same line to 'run_client' file in the Boinc folder as well. Also if a dual core then you may also need to reboot (as I needed to with a dual core Opteron).

(space lines added and made bold by me. thanks conan:)

Please make sure that this issue won't be solved until the next version of charmm is published.

Also, please let us know if you couldn't solve the issue by doing in that way.

Thanks for reading,
suguruhirahara

I converted a computer (1348) to Ubuntu 6.10. the "unlimit -s unlimited" is in the run_client and run_manager, but it still errors.

The computer ran D@H with no problems under W2K and runs Tanpaku and Malaria under the Linux install with no problems.

I'm going to wipe the disk and do a fresh Linux install to see if that fixes the issue.

I converted a computer (1348) to Ubuntu 6.10. the "unlimit -s unlimited" is in the run_client and run_manager, but it still errors.

The computer ran D@H with no problems under W2K and runs Tanpaku and Malaria under the Linux install with no problems.

I'm going to wipe the disk and do a fresh Linux install to see if that fixes the issue.

How did you install BOINC? From the Ubuntu repository or by getting the client from Berkeley's site?

If from the Ubuntu repository you need to edit the /etc/init.d/boinc-client file for "ulimit -s unlimited" to work properly.

Fresh Linux install worked.....now is 1358.

I don't know what happened the first time.

Is a new application for linux fixing this already in developement? Any update on progress?
Other projects like Rosetta crash with this ulimit setting on my ubuntu 6.10 computer :(
____________

Is a new application for linux fixing this already in developement? Any update on progress?
Other projects like Rosetta crash with this ulimit setting on my ubuntu 6.10 computer :(

Can't say that I've noticed this either. I have had issues with 5.8.x clients and Rosetta (and WCG) though.
____________

No unfortunately, no server-side solution yet; we've tried a couple of things already, but none worked without the ulimit workaround.

It cannot be that rosetta doesn't work with the ulimit set to unlimited; all Suse linux boxes come with this set to unlimited by default and I know many people that run rosetta fine with that. It must be something else on your machine that breaks it.

Andre

Is a new application for linux fixing this already in developement? Any update on progress?
Other projects like Rosetta crash with this ulimit setting on my ubuntu 6.10 computer :(

Where do you set the ulimit -s unlimited when using Gentoo Linux? I don't have any run_manager or run_client, Gentoo uses /etc/init.d/boinc to start/stop Boinc. I guess it's a script but have no idea where to put the ulimit code. I've tried writing it directly in the boinc script, without success.

Any other Gentoo users here who can help me?

Any other Gentoo users here who can help me?

I can't get this to work at all - setting ulimit -s unlimited on the command line as super user works, though only for a short time. When I run ulimit -s a few minutes later, it's back to the initial 8192... Causing all work units to error out.

I've searched the Gentoo forums and google without luck, does anyone here know Gentoo and can help me? I'm running kernel version 2.6.18-gentoo-r6.

OK, I think I solved this myself: adding the ulimit code in /root/.bashrc seems to have solved it; one workunit has run for 1.5 hours now, without erroring out.

And then the error came... this time the work unit crunched for almost 2 hours before erroring out. Ulimit now stays at unlimited, but it still hasn't helped. I've now put this project on standby on all Linux machines, until I get it fixed.
Any ideas what I can try now?

One thought: Ulimit is set for root, but Boinc runs as special user boinc. However, I can't log in as user boinc and change anything, so is it possible to set ulimit for this user in any way? Can this even be the problem?
Running ulimit as normal user shows the old 8192 value, so root does not set it for all users.

As an experiment, could you run boinc under the root user? Just remove the 'su ${BOINC_USER} -c ' part of the start line.

Another thing to try is to give the boinc user a shell (in /etc/passwd change /bin/false to /bin/bash or so) and a password (use the passwd command). Then create a .bashrc file for the boinc user with the ulimit -s unlimited line and store that in the boinc user's homedir.

Thanks
Andre

And then the error came... this time the work unit crunched for almost 2 hours before erroring out. Ulimit now stays at unlimited, but it still hasn't helped. I've now put this project on standby on all Linux machines, until I get it fixed.
Any ideas what I can try now?

One thought: Ulimit is set for root, but Boinc runs as special user boinc. However, I can't log in as user boinc and change anything, so is it possible to set ulimit for this user in any way? Can this even be the problem?
Running ulimit as normal user shows the old 8192 value, so root does not set it for all users.

Finally it works! The solution was indeed to put the code in the start script, which runs as user "boinc". I did do this before but thought it didn't work because running ulimit -s showed 8192 as both root and normal user.

Thanks for the help everyone!

It's probably more than a workaround than a real solution, but at least it works :-)

Cheers
Andre

Finally it works! The solution was indeed to put the code in the start script, which runs as user "boinc". I did do this before but thought it didn't work because running ulimit -s showed 8192 as both root and normal user.

Thanks for the help everyone!

The new 5.8.11 client seems to allow the ulimit command to work again on my FC6 host.
____________
BOINC WIKI

BOINCing since 2002/12/8

Is the ulimit command still required?
Im currently upgrading everything to 5.8.11 for my return to docking so it would be nice to know
____________

Is the ulimit command still required?
Im currently upgrading everything to 5.8.11 for my return to docking so it would be nice to know

I decided to play it safe for now and upgraded my little farm to 5.8.11 and put the ulimit fix into all of them just in case lol
____________

Is the ulimit command still required?
Im currently upgrading everything to 5.8.11 for my return to docking so it would be nice to know

As the news in yesterday shows that issue was fixed in the version. As I didn't try it on linux I'm not fully sure, but probably so.

I took "ulimit" out of the script. D@H crashed the WU in 23 minutes.

I took "ulimit" out of the script. D@H crashed the WU in 23 minutes.

Before or after removing ulimit?

Allright, then, we need to add ulimit option in the files yet.
____________

I'm a volunteer participant; my views are not necessarily those of Docking@Home or its participating institutions.

Allright, then, we need to add ulimit option in the files yet.

Correct. We still haven't found a served-side solution for this. To go to beta phase, we will need a solution though, so if anybody has any bright ideas.. :-)

Thanks
Andre

Allright, then, we need to add ulimit option in the files yet.

Good to see you back Suguru! Haven't seen you for a while.
AK

Allright, then, we need to add ulimit option in the files yet.

Good to see you back Suguru! Haven't seen you for a while.
AK

Allright, then, we need to add ulimit option in the files yet.

I know it can be confusing to say that that 5.8.11 has a ulimit fix, but it doesn't fix the ulimit problem.

Basically, somewhere around 5.8.8, the boinc client from Berkeley was modified in a way that resulted in lowering the stack limit from unlimited to 500 MB (IIRC) and this broke Charmm so Andre asked them to change it.

FYI, I don't think Charmm actually uses 500 MB of stack, but I do think that setting the stack limit to unlimited changes the way a segment fault is handled. I suspect that Fortran is doing something that confuses the logic for growing the stack. Of course, that's just my opinion :-) I'm going through the kernel source to try to find out for sure.

____________
The views expressed are my own.
Facts are subject to memory error :-)
Have you read a good science fiction novel lately?

Hi all,

We have finally found and implemented a fix for the stack limit problem! It's a simple (but initially non-obvious) solution where the boinc client starts a shell script that first sets the ulimit to unlimited and then starts Charmm. David Anderson attended us on the fact the boinc client can start shell scripts without any problems and this triggered the solution. So from charmm version 5.4 for linux (32 and 64 bit) you won't need the ulimit fix anymore :-)

This is probably a solution that we won't need anymore when we start using the new charmm version (no, it still hasn't arrived) as this version does not seem to have the stack limit problem.

Thanks for your patience on this.
Andre

I know it can be confusing to say that that 5.8.11 has a ulimit fix, but it doesn't fix the ulimit problem.

Basically, somewhere around 5.8.8, the boinc client from Berkeley was modified in a way that resulted in lowering the stack limit from unlimited to 500 MB (IIRC) and this broke Charmm so Andre asked them to change it.

FYI, I don't think Charmm actually uses 500 MB of stack, but I do think that setting the stack limit to unlimited changes the way a segment fault is handled. I suspect that Fortran is doing something that confuses the logic for growing the stack. Of course, that's just my opinion :-) I'm going through the kernel source to try to find out for sure.

Hi all,

We have finally found and implemented a fix for the stack limit problem! It's a simple (but initially non-obvious) solution where the boinc client starts a shell script that first sets the ulimit to unlimited and then starts Charmm. David Anderson attended us on the fact the boinc client can start shell scripts without any problems and this triggered the solution. So from charmm version 5.4 for linux (32 and 64 bit) you won't need the ulimit fix anymore :-)

This is probably a solution that we won't need anymore when we start using the new charmm version (no, it still hasn't arrived) as this version does not seem to have the stack limit problem.

Thanks for your patience on this.
Andre

I know it can be confusing to say that that 5.8.11 has a ulimit fix, but it doesn't fix the ulimit problem.

Basically, somewhere around 5.8.8, the boinc client from Berkeley was modified in a way that resulted in lowering the stack limit from unlimited to 500 MB (IIRC) and this broke Charmm so Andre asked them to change it.

FYI, I don't think Charmm actually uses 500 MB of stack, but I do think that setting the stack limit to unlimited changes the way a segment fault is handled. I suspect that Fortran is doing something that confuses the logic for growing the stack. Of course, that's just my opinion :-) I'm going through the kernel source to try to find out for sure.

This means you don't have to set it in your scripts in the future. It doesn't matter if these ulimit commands are in your scripts or not, it will just be set to unlimited twice (twinlimited ;-)

Thanks
Andre

Hi all,

We have finally found and implemented a fix for the stack limit problem! It's a simple (but initially non-obvious) solution where the boinc client starts a shell script that first sets the ulimit to unlimited and then starts Charmm. David Anderson attended us on the fact the boinc client can start shell scripts without any problems and this triggered the solution. So from charmm version 5.4 for linux (32 and 64 bit) you won't need the ulimit fix anymore :-)

This is probably a solution that we won't need anymore when we start using the new charmm version (no, it still hasn't arrived) as this version does not seem to have the stack limit problem.

Thanks for your patience on this.
Andre

I know it can be confusing to say that that 5.8.11 has a ulimit fix, but it doesn't fix the ulimit problem.

Basically, somewhere around 5.8.8, the boinc client from Berkeley was modified in a way that resulted in lowering the stack limit from unlimited to 500 MB (IIRC) and this broke Charmm so Andre asked them to change it.

FYI, I don't think Charmm actually uses 500 MB of stack, but I do think that setting the stack limit to unlimited changes the way a segment fault is handled. I suspect that Fortran is doing something that confuses the logic for growing the stack. Of course, that's just my opinion :-) I'm going through the kernel source to try to find out for sure.

Does this make having the ulimit in the script a problem now or we just don't have to use it in the future?