Project

General

Profile

Actions

Bug #3171

closed

File upload regression with --disable-lfs

Added by dani254 3 months ago. Updated 3 months ago.

Status:
Fixed
Priority:
Normal
Category:
core
Target version:
ASK QUESTIONS IN Forums:
Yes

Description

Hello,
I am using lighttpd on an embedded device.
Since the update from 1.4.64 to 1.4.66 the file upload does not work anymore.
I am trying to upload a 10Mb image file. The upload always stops between 6-7 Mb, but not at exactly the same place.

Implemented via mod_cgi and
server.stream-request-body = 1
In the log/trace files you will find pdd_web_nms.cgi which refreshes the browser every three seconds. The actual upload cgi program is called files.cgi.
It seems this is being killed by something.

The upload works with
server.stream-request-body = 0.
But here I get over 60000 ighttpd-upload* tmp files. This seems to me also not stable in the long run.

The attached strace is the last 160kb copy/paste of the console. A complete trace did not fit on the file system of the device.

Best regards
Daniel


Files

syslog.log (840 Bytes) syslog.log dani254, 2022-09-05 10:02
lighttpd.conf (1.85 KB) lighttpd.conf dani254, 2022-09-05 10:02
lighttpd.trace (162 KB) lighttpd.trace dani254, 2022-09-05 10:02
config.log (159 KB) config.log dani254, 2022-09-05 10:02
1.4.64_config.h (14.5 KB) 1.4.64_config.h dani254, 2022-09-08 18:07
1.4.65_config.h (14.6 KB) 1.4.65_config.h dani254, 2022-09-08 18:07
startupLighttpd.trace (998 KB) startupLighttpd.trace dani254, 2022-09-12 12:59
flist.txt (90.9 KB) flist.txt lighttpd-upload* files dani254, 2022-09-13 10:36
lighttpd_tmpdir.trace.gz (4.49 MB) lighttpd_tmpdir.trace.gz strace multiple upload dirs dani254, 2022-09-13 13:37
Actions #1

Updated by gstrauss 3 months ago

  • Status changed from New to Need Feedback

I am trying to upload a 10Mb image file.

The upload works with server.stream-request-body = 0.
But here I get over 60000 ighttpd-upload* tmp files. This seems to me also not stable in the long run.

It seems to me that you have not yet tried skimming through the lighttpd documentation.
Please see the lighttpd wiki, specifically Configuration: Options server.upload-dirs and server.upload-temp-file-size

Actions #2

Updated by dani254 3 months ago

I now made tests with
server.upload-dirs = ( "/opt-pdd", "/tmp" )

server.stream-request-body = 1
and:
server.upload-temp-file-size = 15728640 //whole upload would fit in here
server.upload-temp-file-size = 16384
server.upload-temp-file-size = 4096

All three without success. It fails at different progress points and I got different number of lighttpd-upload* files during upload.

I am on a small embedded device with slow flash disk
Is server.stream-request-body = 1 the right choice?
Is this behavior expected?
Is the configuration the problem?

Actions #3

Updated by dani254 3 months ago

I also built against 1.4.65. The error occurs here as well. So the regression was between 1.4.64 and 1.4.65. Maybe this is helpful.

Actions #4

Updated by gstrauss 3 months ago

Thank you for helping narrow it down to between 1.4.64 and 1.4.65. I'll dig into this issue this weekend, if not sooner.

Is server.stream-request-body = 1 the right choice?

Probably not for you. Are you processing the file by the CGI while it is being uploaded? Or do you process it after the file has been uploaded completely? If the latter, then server.stream-request-body = 0 is the right choice for you.

What client and what client version are you using to upload the file?

Actions #5

Updated by gstrauss 3 months ago

Is this behavior expected?

(chunk.c.780) opening temp-file failed: /opt-pdd/lighttpd-upload-y6zw4v: Interrupted system call

That is not expected.

man 2 open

EINTR While blocked waiting to complete an open of a slow device (e.g., a FIFO; see fifo(7)), the call was interrupted by a signal handler; see signal(7).

What filesystem type is your flash? If your system has enough memory for the file uploads, you might use "/dev/shm" as the first entry in server.upload-dirs = ( "/opt-pdd", "/tmp" ), or place "/tmp" first if "/tmp" is tmpfs.

lighttpd does not currently use SA_RESTART with SIGINT. Doing so globally across the entire lighttpd process might lead to unintented consequences and would need to be explored more deeply. Instead, maybe I'll add a retry loop to retry up to 3 times if the mkostemp() fails with EINTR.

It may be useful to me if you could compare config.h from your builds of lighttpd 1.4.64 and lighttpd 1.4.65.

Actions #6

Updated by gstrauss 3 months ago

Is lighttpd receiving a signal which interrupts the system call? What signal? Try capturing strace -o strace.log -p <lighttpd-pid> during any upload request.

Updated by dani254 3 months ago

My clients are running Edge on Windows and Firefox on Linux.
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36 Edg/105.0.1343.27"
"Mozilla/5.0 (X11; Linux x86_64; rv:105.0) Gecko/20100101 Firefox/105.0"

/tmp and the entire Linux are in RAM. But here is only 5 Mb free. If I swap the upload directories, the connection breaks exactly after 5MB.
/opt-pdd is on a NOR flash.

the configs.h are attached

I try to narrow down the problem by testing single commits. So far I have:

  • 71317bc9 - (HEAD) [tests] test stubs for http_header.c and http_kv.c (3 months ago) <Glenn Strauss> - Fail - file upload
  • 5c4cc9f5 - (HEAD) [core] avoid server.use-ipv6 warning after SIGUSR1 (3 months ago) <Glenn Strauss> - Fail - no cgi, Network Protocol Error
  • 5e0d82dc - (HEAD) [core] reusable code for r->state strings (4 months ago) <Glenn Strauss> - Fail - no cgi, Network Protocol Error
  • c183b887 - (HEAD) [core] delay response to http auth invalid creds (4 months ago) <Glenn Strauss> - Fail - no cgi, Network Protocol Error
  • 63beba3a - (HEAD) [core] allow redirect,rewrite ext subst w/o pcre (5 months ago) <Glenn Strauss> - OK - file upload
  • 1f4cc747 - (HEAD) [core] chunkqueue_steal() handle unexpected 0 len (6 months ago) <Glenn Strauss> - OK - file upload
  • 2d1b1672 - (HEAD) [core] chunk_file_pread() to wrap pread() (7 months ago) <Glenn Strauss> - OK - file upload

Can you recommend a commit that I should test?

(back on Monday)

Actions #8

Updated by dani254 3 months ago

strace was attached in the first post. Was it valuable? If not I make another one on Monday.

Actions #9

Updated by gstrauss 3 months ago

Besides version number change (expected), I do not see any substantive differences between 1.4.64_config.h and 1.4.65_config.h

From the original strace:

13:03:00.600816 open("/opt-pdd/lighttpd-upload-y6zw4v", O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0600) = -1 EINTR (Interrupted system call)
13:03:00.634685 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1389, si_uid=0, si_status=0, si_utime=0, si_stime=1} ---
13:03:00.636150 rt_sigreturn({mask=[]}) = -1 EINTR (Interrupted system call)
13:03:00.639544 send(6, "<27>Aug 25 13:03:00 lighttpd[1264]: (chunk.c.780) opening temp-file failed: /opt-pdd/lighttpd-upload-y6zw4v: Interrupted system call", 132, MSG_NOSIGNAL) = 132

lighttpd uses sigaction to set SA_RESTART flag for SIGCHLD, so the open() should not be interrupted unless something changed in preprocessor detection and sigaction is not being used on your system. However, your config.h shows HAVE_SIGACTION detected for both lighttpd 1.4.64 and 1.4.65.

Would you strace lighttpd at startup to confirm that SA_RESTART is being set for SIGCHLD?

Actions #10

Updated by gstrauss 3 months ago

The original strace appears to show your CGI program exiting before the upload is complete. Are you perhaps backgrounding the CGI to detach the process from lighttpd?

While I am still interested in tracking down why this behavior changed for you, if your CGI script does not need to process the request body until after the request body is completely uploaded, then server.stream-request-body = 0 is recommended.

Actions #11

Updated by dani254 3 months ago

I attached a startup trace. files.cgi is the actual upload cgi. I had to stop the strace before the lost connection because of disk space.

> The original strace appears to show your CGI program exiting before the upload is complete. Are you perhaps backgrounding the CGI to detach the process from lighttpd?
That is the problem when the connection gets lost. I thought files.cgi was killed by lighttpd after the "(chunk.c.780) opening temp-file failed" No backgrounding. strace was manually stopped by me after the lost connection, because of disk space.

if your CGI script does not need to process the request body until after the request body is completely uploaded, then server.stream-request-body = 0 is recommended.
files.cgi is creating an upload tmp file q_xxxxx~. pdd_web_nms.cgi is called every three seconds by javascript to monitor the file-size of the q_xxxxx~ tmp file with readdir(DIR *dirp) and stat(const char *path, struct stat *buf). After upload q_xxxxx~ is renamed to the target file.
Does stat() count as "processing the request body"?

I tried it again with server.stream-request-body = 0. It works , but with up to 90000 lighttpd-upload* tmp files. Do you judge this to be harmless?

Second I tried server.stream-request-body = 0 and server.upload-dirs = ( "/tmp", "/opt-pdd" ). /tmp is fast RAM, but only 5 Mb free disk space. The connection was lost after /tmp was filled up. Shouldn't there be a fallback to /opt-pdd?

Actions #12

Updated by gstrauss 3 months ago

I attached a startup trace. files.cgi is the actual upload cgi. I had to stop the strace before the lost connection because of disk space.

00:33:19.175820 rt_sigaction(SIGCHLD, {sa_handler=0x100074f0, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO|SA_NOCLDSTOP}, NULL, 8) = 0

I see that SA_RESTART is being set for SIGCHLD, so why lighttpd call to open() is being interrupted and not restarted is a mystery. open() is explicitly listed as restartable in man 7 signal for a signal configured with SA_RESTART.

Does stat() count as "processing the request body"?

Yes, but you might instead consider using mod_magnet lua mod_uploadprogress for that part.

I tried it again with server.stream-request-body = 0. It works , but with up to 90000 lighttpd-upload* tmp files. Do you judge this to be harmless?

Did you clear the temporary directories before you restarted with server.stream-request-body = 0 ?
(lighttpd is unable to clean up those temporary files if created by mkostemp and not reported as success by mkostemp due to EINTR)
Did you modify server.upload-temp-file-size ? The default is 1 MB. If you see lots and lots of temp files, what are their sizes?

Second I tried server.stream-request-body = 0 and server.upload-dirs = ( "/tmp", "/opt-pdd" ). /tmp is fast RAM, but only 5 Mb free disk space. The connection was lost after /tmp was filled up. Shouldn't there be a fallback to /opt-pdd?

Yes, I have previously tested that the fallback works when ENOSPC occurs. Do you have an strace of that failing?

Actions #13

Updated by gstrauss 3 months ago

I attached a startup trace. files.cgi is the actual upload cgi. I had to stop the strace before the lost connection because of disk space.

00:33:19.175820 rt_sigaction(SIGCHLD, {sa_handler=0x100074f0, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO|SA_NOCLDSTOP}, NULL, 8) = 0

I see that SA_RESTART is being set for SIGCHLD, so why lighttpd call to open() is being interrupted and not restarted is a mystery. open() is explicitly listed as restartable in man 7 signal for a signal configured with SA_RESTART.

... If you know some C, I would suggest writing a small test program to see if you could interrupt an open() in a program with signal SIGCHLD with SA_RESTART set by sending a SIGCHLD to the program during the open().

If you recently upgraded the OS or glibc on your system, I would test with an older version. If you haven't upgraded your OS or glibc recently, I would check for and test an upgraded version.

Actions #14

Updated by gstrauss 3 months ago

To repeat:
lighttpd is unable to clean up those temporary files if created by mkostemp and not reported as success by mkostemp due to EINTR.
You must manually delete those files before you continue your testing.
lighttpd is not creating 90000 lighttpd-upload* tmp files for a single 10 MB upload. (By default, lighttpd might create ten (10) temp files, each 1 MB in size)

Actions #15

Updated by dani254 3 months ago

lighttpd is unable to clean up those temporary files if created by mkostemp and not reported as success by mkostemp due to EINTR.
You must manually delete those files before you continue your testing.

I always checked the directories for orphaned lighttpd-upload* tmp files. But this was never necessary. lighttpd always cleaned up after a connection loss and deleted all tmp files.

lighttpd is not creating 90000 lighttpd-upload* tmp files for a single 10 MB upload.

Oops!, indeed, sorry, I counted bytes not lines.

(By default, lighttpd might create ten (10) temp files, each 1 MB in size)

server.upload-temp-file-size is the max size, isn't it? I got hundreds of small files.

again: single upload dir server.upload-dirs = ("/opt-pdd") , server.stream-request-body = 0 , default server.upload-temp-file-size
it is working, about 1100 tmp files. I've attached the output of ls -l lighttpd-upload* > /tmp/flist.txt near its peak.
If you confirm this is correct and healthy, I will follow this solution.

Actions #16

Updated by dani254 3 months ago

... If you know some C, I would suggest writing a small test program to see if you could interrupt an open() in a program with signal SIGCHLD with SA_RESTART set by sending a SIGCHLD to the program during the open().

Do you maybe have a kind of "stackoverflow" example where I could start?
Linux is 3.10.28, libc-2.18.so, Unfortunately I can not change this.

Actions #17

Updated by dani254 3 months ago

Second I tried server.stream-request-body = 0 and server.upload-dirs = ( "/tmp", "/opt-pdd" ). /tmp is fast RAM, but only 5 Mb free disk space. The connection was lost after /tmp was filled up. Shouldn't there be a fallback to /opt-pdd?

Yes, I have previously tested that the fallback works when ENOSPC occurs. Do you have an strace of that failing?

Here an nearly complete strace (1000 lines removed from the middle), default server.upload-temp-file-size.

Actions #18

Updated by gstrauss 3 months ago

  • Status changed from Need Feedback to Patch Pending
  • Target version changed from 1.4.xx to 1.4.67

With the addition of use of pwritev() on systems where it is available, I missed adding a retry for ENOSPC. Here is a patch:

--- a/src/chunk.c
+++ b/src/chunk.c
@@ -1011,6 +1011,8 @@ static ssize_t chunkqueue_append_cqmem_to_tempfile(chunkqueue * const restrict d
             chunkqueue_mark_written(dest, dlen);
         }
     }
+    else if (chunkqueue_append_tempfile_err(dest, errh, c))
+        wr = 0; /*(to trigger continue/retry in caller rather than error)*/

     return wr;
 }

With the above patch, please try using server.upload-dirs = ( "/dev/shm", "/opt-pdd" ). Please use "/dev/shm". Does it exist on your system? (If not, use "/tmp" instead of "/dev/shm".) As I recall, /dev/shm is available since the Linux 2.6 kernel, but must be mounted. How much memory does your system have? How much free memory during normal operation? "/dev/shm" is by default 1/2 available RAM, so if even on paltry embedded systems with only 32 MB of RAM, "/dev/shm" might be used to temporarily store the entire 10MB upload and then pass the upload on to the CGI much more quickly than using temporary files on slow disk. Even if "/dev/shm" is not large enough, the above patch will use "/dev/shm" and then fall back to "/opt-pdd" for the rest.

Do you maybe have a kind of "stackoverflow" example where I could start?
Linux is 3.10.28, libc-2.18.so, Unfortunately I can not change this.

Maybe some other time. Would you confirm that things still work with lighttpd 1.4.64 and that there have been no other changes on your system besides the upgrade to lighttpd 1.4.65 (or lighttpd 1.4.66)? I have a hunch that things will work with lighttpd 1.4.64, and that the primary reason they do not work with lighttpd 1.4.65 is the creation of an excessive number of tempfiles, which provides more opportunity for interruption. I have a feeling that sigaction for SIGCHLD with SA_RESTART is not working on your system, but that there are fewer opportunities for interruption with lighttpd 1.4.64 than lighttpd 1.4.65.

Your short-term workarounds to the upload interruption include:
a) server.upload-dirs = ( "/dev/shm", "/opt-pdd" ) (with patch above)
b) server.stream-request-body = 0
c) do not fork the CGI into the background until after the upload is complete
d) disable the upload progress feature or replace with mod_magnet lua mod_uploadprogress
(In any case, I recommend all of the above anyway.)

... I am now about to start looking into why you might be seeing so many temporary files of such small sizes, when they should grow to 1 MB (by default) before a new tempfile is started. 1100 temp files is too many for a 10 MB upload, where I would expect 10 temp files.

Actions #19

Updated by gstrauss 3 months ago

What is INTMAX_MAX defined to on your embedded system? Is INTMAX_MAX properly defined in your build environment?
Use the appropriate cross-compiler flags with the following to get the value for the embedded system build.
echo "#include <stdint.h>" | gcc -dM -E - | grep "define INTMAX_MAX"

Actions #20

Updated by gstrauss 3 months ago

I have not been able to reproduce the many, many tempfiles you are seeing.

For a CGI backend and server.stream-request-body = 0, the default lighttpd behavior is to create a single tempfile and then attach that to CGI stdin. I confirmed that I see this behavior on my machine. Similarly, I confirmed that when server.stream-request-body = 1, lighttpd creates multiple 1MB tempfiles if the backend delays reading CGI stdin.

In your strace lighttpd_tmpdir.trace.gz, I see that lighttpd is performing a single pwritev() to a tempfile, writing approx 4k - 16k. When more data is available, the tempfile is closed and a new one is opened. That should not happen unless the tempfile has exceeded cq->upload_temp_file_size: https://git.lighttpd.net/lighttpd/lighttpd1.4/src/branch/master/src/chunk.c#L801

Did you notice any change in temporary files sizes when you tested with different settings of server.upload-temp-file-size = 1048576 ? Please make sure that you properly restart lighttpd after making changes to lighttpd.conf.

Actions #21

Updated by gstrauss 3 months ago

Please do a clean and full build of lighttpd 1.4.66 with the patch above to test.

Actions #22

Updated by dani254 3 months ago

echo "#include <stdint.h>" | powerpc-linux-gcc -dM -E - | grep "define INTMAX_MAX" 
#define INTMAX_MAX (__INT64_C(9223372036854775807))

I see no differences between 1.4.65 and 1.4.66
I have disabled javascript, so no processing of the uploaded file with stat
I have no /dev/shm but /tmp is a ramdisk with 5Mb free.

1.4.66 patched WORKING (unpatched is not working)
1.4.65 patched WORKING
server.upload-dirs = ( "/tmp", "/opt-pdd/" )
server.stream-request-body = 1
several (5-9?) 1Mb lighttpd-upload- files distributed between /tmp and /opt-pdd

1.4.66 patched WORKING
1.4.65 patched WORKING
server.upload-dirs = ( "/opt-pdd" )
server.stream-request-body = 1
one lighttpd-upload- file < 1MB in /opt-pdd
indeed it is NOT working if I process the uploaded tmp file with stat() -> connection loss

1.4.65 patched WORKING
1.4.65 patched WORKING
server.upload-dirs = ( "/opt-pdd" )
server.stream-request-body = 0
about 1000 lighttpd-upload- files in /opt-pdd

1.4.66 patched WORKING
1.4.65 patched WORKING
server.upload-dirs = ( "/tmp", "/opt-pdd" )
server.stream-request-body = 0
about 1000 lighttpd-upload- files distributed between /tmp and /opt-pdd
size between 384 - 16000 bytes, 16000 seems to be the maximum!
I tried server.upload-temp-file-size = 8192, but this is not respected. max filesize is still 16000

So it seems
server.upload-dirs = ( "/tmp", "/opt-pdd/" )
server.stream-request-body = 1
is what you expect with
server.upload-dirs = ( "/tmp", "/opt-pdd/" )
server.stream-request-body = 0 ?

Actions #23

Updated by dani254 3 months ago

It may be of interest, the powerpc cpu is 32bit big-endian

Actions #24

Updated by gstrauss 3 months ago

I do not think that I understand the way the you structured your post with "WORKING" and then describing not working.

With server.upload-dirs = ( "/opt-pdd" ) and server.stream-request-body = 0, I expect a single temp file in /opt-pdd.

With server.upload-dirs = ( "/tmp", "/opt-pdd/" ) and server.stream-request-body = 0, I expect a handful tempfiles, with one in /tmp, and then the rest in /opt-pdd.

With server.upload-dirs = ( "/tmp", "/opt-pdd/" ) and server.stream-request-body = 1, I expect a handful tempfiles, with some in /tmp, and then the rest in /opt-pdd, but the number also depends on how quickly the backend processes the request body.

It may be of interest, the powerpc cpu is 32bit big-endian

Yes. it is.

Did you test again with lighttpd 1.4.64? Is that still working WITHOUT creating an excessing number of temp files?

Actions #25

Updated by gstrauss 3 months ago

You posted

server.upload-dirs = ( "/opt-pdd" )
server.stream-request-body = 0
about 1000 lighttpd-upload- files in /opt-pdd

That suggests to me that when lighttpd mod_cgi tries to create a single tempfile by setting
                /* store request body in single tempfile if not streaming request body*/
                r->reqbody_queue.upload_temp_file_size = INTMAX_MAX;

that on your system it results in a negative number in r->reqbody_queue.upload_temp_file_size such that tests in chunk.c:
if (c->file.length < (off_t)cq->upload_temp_file_size)
always fail, resulting in creation of a new temp file for each new write of ~4k - ~16k.

cq->upload_temp_file_size is of type (off_t) and lighttpd should always be built with 64-bit file support, so (off_t) should be the same size as (int64_t)

In lighttpd 1.4.60, mod_cgi was changed to use a single temp file if not streaming.
https://git.lighttpd.net/lighttpd/lighttpd1.4/commit/70195d069d7baf7ecb53db186176f1dee61817f5
You can try setting server.feature-flags += ("cgi.tempfile-accum" => "disable") to disable this feature and see if that makes the number of temp files with server.stream-request-body = 0 reduce to about 10 temp files.

What does your compiler say for echo "#include <stdint.h>" | powerpc-linux-gcc -dM -E - | grep OFF ?

Your issue likely stems from your system not sizing (off_t) to (int64_t) for large filesystem support.

--- a/src/mod_cgi.c
+++ b/src/mod_cgi.c
@@ -1028,7 +1028,8 @@ URIHANDLER_FUNC(cgi_is_handled) {
            && !(r->conf.stream_request_body /*(if not streaming request body)*/
                 & (FDEVENT_STREAM_REQUEST|FDEVENT_STREAM_REQUEST_BUFMIN))) {
                /* store request body in single tempfile if not streaming request body*/
-               r->reqbody_queue.upload_temp_file_size = INTMAX_MAX;
+               r->reqbody_queue.upload_temp_file_size =
+                 (off_t)((1uLL << (sizeof(off_t)*8-1))-1);
        }

        {

Actions #26

Updated by gstrauss 3 months ago

If (sizeof(off_t) != sizeof(int64_t)), your cross-compiler is not operating as lighttpd expects since lighttpd expects to be able to force large file support in lighttpd builds. The patch above attempts to work around that. On your system, you should see an excessive number of upload temp files created if using server.stream-request-body = 0 and any version of lighttpd 1.4.60 through lighttpd 1.4.66.

Separately, your system is broken in some way if open() is being interrupted by SIGCHLD when SIGCHLD has been configured with sigaction() and flag SA_RESTART. Workarounds for you have been suggested in a post further above, including deferring your fork and backgrounding of your CGI until after the upload request body has been fully received, or server.stream-request-body = 1 with server.upload-temp-file-size = 15728640 //whole upload would fit in here, along with the pwritev() retry patch further above.

Actions #27

Updated by dani254 3 months ago

Did you test again with lighttpd 1.4.64? Is that still working WITHOUT creating an excessing number of temp files?

I tried it again. No it is not working at all. Number of temp files > 10000.

I do not think that I understand the way the you structured your post with "WORKING" and then describing not working

With WORKING I meant: I get a complete upload file

that on your system it results in a negative number in r->reqbody_queue.upload_temp_file_size such that tests in chunk.c:

You are exactly right. I did some printf at startup to test:

server.c:2070:main  sizeof(int64_t): 8
server.c:2071:main  sizeof(off_t): 4
Error size differs
server.c:2073:main  INTMAX_MAX: 9223372036854775807
server.c:2075:main  intmaxcast: -4294966784

Now I have
1.4.66 two patches WORKING
server.upload-dirs = ( "/opt-pdd" )
server.stream-request-body = 0
server.feature-flags += ("cgi.tempfile-accum" => "disable")
ten lighttpd-upload- files in /opt-pdd

1.4.66 two patches WORKING
server.upload-dirs = ( "/opt-pdd" )
server.stream-request-body = 1
server.upload-temp-file-size = 15728640
one lighttpd-upload- files in /opt-pdd

I am very happy with it. Thank you for your great work and much patience.
I will be out of office for the next week if there are any questions for me.

Will the two patches merged to the master?

Actions #28

Updated by gstrauss 3 months ago

Your problem stems from your own build configuration:
$ ./configure --host=powerpc-linux --build=i386-gnu-linux --prefix=/usr --libdir=/lib/lighttpd --sysconfdir=/etc/lighttpd --with-pam --disable-lfs --without-pcre --without-pcre2 --without-bzip2 --without-zlib --with-openssl=/tmp/NMS/powerpc/eldk-5.5.3

The --disable-lfs is not recommended. Why did you include it? What do you think it gains you?

If your interest is in executable size, then you should consider using mbedtls instead of openssl.

Please consider removing --disable-lfs from your build. There may very well be other places in lighttpd that fail with small off_t. You are not using a recommended or well-tested config.


Also, your system mishandling SA_RESTART is a separate issue with your system.

Actions #29

Updated by gstrauss 3 months ago

  • Subject changed from File upload regression from 1.4.64 to 1.4.66 to File upload regression with --disable-lfs

lighttpd 1.4.67 auotconf build will force large file system support and will ignore --disable-lfs

lighttpd meson, CMake, and SCons builds already force large file system support.

Actions #30

Updated by gstrauss 3 months ago

@dani254 while this issue will be closed, you still have an issue on your system:

Your system is broken in some way if open() is being interrupted by SIGCHLD when SIGCHLD has been configured with sigaction() and flag SA_RESTART.

While the changes above make the interrupted open() much less likely to occur, the problem on your system remains and you should look into it.

Actions #31

Updated by gstrauss 3 months ago

  • Status changed from Patch Pending to Fixed
Actions

Also available in: Atom