Feature #2802

Could the error-log be improved a tiny bit in regards to "Permission denied" errors propagated from the filesystem (on Linux at the least)?

Added by shevegen 6 months ago. Updated 6 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Missing in 1.5.x:


Hello lighttpd developers,

I have some strange warning/error, partially unrelated to lighttpd,
in my ruby-cgi scripts (yup I am oldschool!). The ruby-cgi scripts
work fine, but about a year or so ago, I made some major changes
to my "framework" and I did not really bother to keep track of all
of it ...

At any rate, debugging this is a little bit difficult for me right
now since I have to dig into a code base that is of some considerable
length and I currently do not have quite the time to dig into that.

But I noticed that lighttpd (version 1.4.45) sort of "dies" silently, in
semi-random way, which I don't think is the problem of lighttpd but more
of some combination of my script. Actually, "dying" is the wrong word -
lighty works just fine, but I also don't see any error, yet some of
the large .cgi pages are not displayed fully but stopped somewhere,
and no real direct error is being recorded in the logs (which is
one additional reason why it is so hard for me to find out where
the culprit is - one day I will re-assemble everything there and
then re-add it together, but right now I lack the time).

Anyway, when I looked at the .log files, in particular:


I noticed an error showing up, although it may be unrelated to
the "real" error that I have yet to find:

2017-03-25 11:16:37: (log.c.217) server started 
2017-03-25 11:16:40: (chunk.c.553) opening temp-file failed: Permission denied

I assume that there is simply some permission error. But
currently I do not know where the temp-file is located.

So here is my feature request relevant for lighttpd:

- Could the error_log above from chunk.c also detail where the
file would be created at?

For example, rather than the above, it could perhaps write:

2017-03-25 11:16:40: (chunk.c.553) opening temp-file failed: Permission denied for /Depot/Temp

Or something like that. (I assume the guilty party may be
the directory that the file would reside in.)

That way I could check the permissions quickly and fix them.

Right now I have no idea where the temp-file should reside. (I
can probably dig into it but currently I don't have much time
for anything, most of my time goes into non-programming related
reallife stuff :( )

Anyway, lighty rocks! I switched away from apache to lighty
some years ago and it's perfectly fine for that use case. (I
got tired of the apache config format; when apache changed
the config format, and I'd have to re-assemble everything
before it would work again, I simply lost interest and
jumped over to lighty.)

Related issues

Related to Bug #2796: mod_fastcgi can fail to read entire response from serverFixed2017-03-08

Associated revisions

Revision 162e754d (diff)
Added by gstrauss 6 months ago

[core] report file path when mkstemp() fails (fixes #2802)

"Could the error-log be improved a tiny bit in regards to "Permission denied" errors"


#1 Updated by gstrauss 6 months ago

  • Related to Bug #2796: mod_fastcgi can fail to read entire response from server added

#2 Updated by gstrauss 6 months ago

  • Category set to mod_cgi
  • Priority changed from Normal to Low
  • Target version changed from 1.4.x to 1.4.46

Thanks for the report. I believe the issue you are seeing with truncated response was fixed in #2796 and will be part of lighttpd 1.4.46. The fix is already part of the lighttpd git master branch.

Regarding where tempfiles are created, the default is /var/tmp (if it exists) or else /tmp. The location is controlled with server.upload-dirs. Another method to figure out where lighttpd is writing is to use use strace and look for the call to open and then the error, in your case, EACCES.

I'll see if the error message can be extended when mkstemp() fails.

#3 Updated by gstrauss 6 months ago

  • Category changed from mod_cgi to core
  • Status changed from New to Patch Pending

#4 Updated by gstrauss 6 months ago

  • Status changed from Patch Pending to Fixed
  • % Done changed from 0 to 100

Also available in: Atom