"too many open files" while importing images
gohrner
Joined: 2005-07-11
Posts: 1 |
![]() |
Hi! Finally I got g2 to work reliably, using PostgreSQL instead of MySQL as the backend db server. However, if I import a lot of image files which are available on the server, gallery2 is busy for some time and then I the following error message: Warning: fopen(/usr/local/share/gallery2-images/locks/1/4/14003): failed to open stream: Too many open files in /usr/share/gallery2/modules/core/classes/GalleryPlatform.class on line 347 Error Detail - Looks as if g2 opeans each image file and never closes the stream. Greetings, Gunter |
|
valiant
Joined: 2003-01-04
Posts: 32509 |
![]() |
Thanks for reporting, I've looked at the code for a few seconds and you may be right. Don't have time right now for a real inspection. |
|
valiant
Joined: 2003-01-04
Posts: 32509 |
![]() |
gohrner, " if I import a lot of image files which are available on the server", what add item method did you choose and how many items did you add at once? |
|
valiant
Joined: 2003-01-04
Posts: 32509 |
![]() |
i've looked at the code and it releases the locks when it should. bottom line: |
|
valiant
Joined: 2003-01-04
Posts: 32509 |
![]() |
i've fixed a small bug in FlockLockSystem.class, but this but is unrelated to your problem. |
|
wsloand
Joined: 2004-07-12
Posts: 17 |
![]() |
I just had the same error with the current (2.1.1-1) debian package (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=365442). Since this error exists and database locking should fix the problem, could database locking be made the default and file locking be a suggested performance enhancement (with the warning about file locking). |
|
Roland B Roberts
Joined: 2006-03-27
Posts: 10 |
![]() |
You need to increase ulimit -n for the webserver. I just ran into this problem while recreating all the resized images on my site. The soft limit is probably much lower than the hard limit, perhaps as low as 1024. That sounds big, but if you are loading a couple hundred files with several images sizes and thumbnails, you may run out of file handles. I strongly suspect something in Gallery or PHP is failing to close some of those file handles when it should (perhaps they are just going out of scope and not being closed right away?). In any event, on my Fedora Core 5 host, I added "ulimit -n 65535" to /etc/sysconfig/httpd and was then able to resize all of my images. |
|
eye1marie
Joined: 2006-05-21
Posts: 13 |
![]() |
wsloand wrote:
I just had the same error with the current (2.1.1-1) debian package (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=365442). Since this error exists and database locking should fix the problem, could database locking be made the default and file locking be a suggestedd performance enhancement (with the warning about file locking). I had thesame problem, but indeed its fixed now. Thanks! |
|
cww
Joined: 2006-08-30
Posts: 2 |
![]() |
I had the same problem when trying to import about 4,000 images from Gallery v1.5.4. It stalled somewhere around 15% with a really long list of errors that started with the thing about having too many open files. Quote:
if you tried to add hundreds or thousands of files at once, this may explain it. The database locking solution worked on PostgreSQL 8.1.4. Thanks! Colin |
|
relegated
Joined: 2009-06-29
Posts: 11 |
![]() |
The database locking also fixed my issue posted here http://gallery.menalto.com/node/88684 |
|
annorax
![]()
Joined: 2002-07-24
Posts: 6 |
![]() |
Roland B Roberts wrote:
You need to increase ulimit -n for the webserver. I just ran into this problem while recreating all the resized images on my site. The soft limit is probably much lower than the hard limit, perhaps as low as 1024. I confirmed that this works on Fedora Core 13 as well; however, I just bumped up the number to 2048 instead of MAXINT. I don't want anything running away on my web server and bringing it resoundingly to it knees. I'll just keep nudging up the number as needed. |
|