View previous topic :: View next topic |
Author |
Message |
Astaroth33 n00b
Joined: 19 Oct 2003 Posts: 36
|
Posted: Mon Nov 17, 2003 7:50 am Post subject: Overnet and file descriptors |
|
|
Anyone run into this? I'm running the Overnet 0.50.1 core (manually installed it, rather than emerging the 0.48.2 that's in portage) with the ed2k-gtk-gui version 0.6.0, and I get the error message "Couldn't create Temp File" repeated almost continuously in its status window. Their documentation http://cvs.sourceforge.net/viewcvs.py/ed2k-gtk-gui/ed2k_gui/docs/en/index-5.html?rev=1.2 states that this is due to not having enough file descriptors available, and suggests a means for changing this.
Running the command
returns a value of 1024, and they suggest editing the file /etc/security/limits.conf to append the following:
Code: | tim hard nofile 4096 |
'tim' is the username you are using, 'hard' stands for 'hard limit', 'nofile' stands for the number of open file descriptors allowed, and 4096 is the value (you might want a higher value, but 4096 should be fine).
This has not had the desired effect on my system. Running "ulimit -n" still reports the same value of 1024. Does Gentoo allow for configuration of this variable? Anyone run into this and had any luck fixing? I've lost partially downloaded files due to this, and would like to prevent this in the future.. Thanks! |
|
Back to top |
|
|
Astaroth33 n00b
Joined: 19 Oct 2003 Posts: 36
|
Posted: Mon Nov 17, 2003 8:44 am Post subject: |
|
|
Thanks to another thread here, it looks like I may have solved my own problem by adding the line
to /etc/profile and then restart X. The ulimit -n command now returns a 4096 value.
|
|
Back to top |
|
|
Astaroth33 n00b
Joined: 19 Oct 2003 Posts: 36
|
Posted: Mon Nov 17, 2003 10:58 am Post subject: |
|
|
I spoke too soon. It seemed like it was working, but then for reasons I cannot explain, it stopped and "ulimit -n" began again to return a value of 1024. Any time a shell was opened, I'd get the error:
Code: | -bash: ulimit: open files: cannot modify limit: Operation not permitted |
So.. time for more research. Digging through google, I found this: http://lists.suse.com/archive/suse-linux-e/2002-Dec/0224.html Now, given that I'm perfectly willing to trash this gentoo install if it means I learn something in the process, I followed the instructions and modified the file. Oddly enough, though I changed the value to 8196, "ulimit -n" is reporting back a value of 4096, and I have no idea why.
Given that I'm still getting "couldn't create temp file" errors in overnet, I'd say that while I'm making progress, I still haven't solved the problem. So I'm going to pound my head against the wall for a while, sleep on it, and then try to figure it out sometime tomorrow.. |
|
Back to top |
|
|
Astaroth33 n00b
Joined: 19 Oct 2003 Posts: 36
|
Posted: Wed Nov 19, 2003 2:12 am Post subject: |
|
|
Last post on this issue, as I think it's now working properly. I am convinced that the kernel recompilation was unneccessary. I believe the correct method is to modify /etc/security/limits.conf as described above and to modify /etc/profile, and have the descriptor values equal to each other. Then restart X.
I had to increase the limit all the way up to 32768 to stop the error messages in the ed2k-gtk-gui status window, btw. So far so good, and hopefully all this will be of good use to someone in the future.. |
|
Back to top |
|
|
tmb n00b
Joined: 03 Jun 2003 Posts: 28
|
Posted: Wed Nov 19, 2003 11:20 pm Post subject: |
|
|
Astaroth33 wrote: | Last post on this issue, as I think it's now working properly. I am convinced that the kernel recompilation was unneccessary. I believe the correct method is to modify /etc/security/limits.conf as described above and to modify /etc/profile, and have the descriptor values equal to each other. Then restart X. |
I have the same problem for the same reason If i login as an ordinary user through ssh (no X) i'm not allowed to run 'ulimit'. Is it the same for you? For obvious reasons it works if logged in as root and su to the user but that doesn't feel like the right way.
I have done the same changes as you to the files but the number of filehandles still are set to 1024 when logging in. Except for root then who has the right privileges.
Someone recommended 'sudo' for doing ulimit as an ordinary user but how should the /etc/sudoers look like for an internal command. Visudo refuses to let me enter a command without the full path.
[Edit: Added below]
After some investigating it seems hard to get ssh/sshd to change these limits even if the pam_limits.so is present in both /etc/pam.d/ssh and /etc/pam.d/sshd. If i login locally on the machine as a regular user i get the limits set as per the instructions in /etc/security/limits.conf. Sshing remotely sets it to 1024. Not even sshing remotely and then doing a ssh locally to localhost has any effect.
Pretty amazing since this issue seems to have been around for several years and i can't for my life find any source that can show a working solution for it. |
|
Back to top |
|
|
rounin Tux's lil' helper
Joined: 13 Apr 2003 Posts: 84
|
Posted: Sat Feb 07, 2004 10:14 pm Post subject: |
|
|
I think it's because the kernel developers actually don't WANT to solve this issue... But I could be wrong. Perhaps they're just ignorant of the fact that people use more than 1024 open files.
It would be interesting to alert them to this fact, but they don't exactly seem eager to be contacted.
I've posted the limits.conf solution at:
http://home.no.net/david/ulimit.html |
|
Back to top |
|
|
|