Feature #2847
closedhandling permissions at startup
Description
Hi guys, I recently had an issue with pihole which uses lighttpd for it's web admin web app. lighttpd wouldn't startup and part of this turned out to be related to me running /var/log on an fstab tmpfs mount.
In the end I resolved the problems I saw by modifying the lighttpd.service to include a handful of extra ExecStartPre directives:
ExecStartPre=/bin/mkdir -p /var/log/lighttpd ExecStartPre=/bin/chown www-data:www-data /var/log/lighttpd ExecStartPre=/bin/mkdir -p /var/run/lighttpd ExecStartPre=/bin/chown www-data:www-data /var/run/lighttpd
I basically ensure the /var/log/lighttpd and /var/run/lighttpd directories exist and ensure they're owned by the user I run lighttpd as. This does work for me but I realize this isn't an ideal solution because these folders and the user are variables within /etc/lighttpd/lighttpd.conf
That led to wonder if there might be a better to fix this potential problem permanently for everyone.
Updated by stbuehler about 7 years ago
Usually it would be your distributions package job to set these things up. If you break it then, I don't think there should be magic repairing it.
If you go for manual install and use the example config.. hm. I still would prefer not to do this automatically. Maybe the warning/error messages could be improved (if necessary)?
Updated by joelippa about 7 years ago
Yes fair point, I'm not a fan of magic fix ups in code either.
To be honest I don't know if running /var/log on a tmpfs mount is a very common setup but it is something that raspberry pi users and armbian users on sbc boards sometimes do to attempt to prolong life expectancy of SD cards.
I guess when a system is setup like this with the default lighttpd example config, it's a case of lighttpd working as expected when first installed and then fail to start after a reboot because the /var/log/lighttpd directory is not there after boot. /var/log is effectively flushed on boot when mounted as tmpfs. From what you've said, I think you're against the idea of lighttpd creating this directory if it's not there.
You might be onto something about the reported errors being improved. In my case the non-existence of the /var/run/lighttpd directory / incorrect permissions on this directory results in this error in the /var/log/lighttpd/error.log which is close to pointing to the root cause problem but could be slightly misleading:
2017-12-10 19:32:36: (mod_fastcgi.c.984) bind failed for: unix:/var/run/lighttpd/php.socket-0 Permission denied
Updated by stbuehler about 7 years ago
The debian package has /usr/lib/tmpfiles.d/lighttpd.tmpfile.conf which should at least ensure the presence of /var/run/lighttpd.
Updated by gstrauss about 7 years ago
- Tracker changed from Bug to Feature
It really is not a bug if you (or your environment) changes.
Still, I'll look at improving the error messages for missing paths.
Updated by gstrauss about 7 years ago
- Status changed from New to Patch Pending
- Target version changed from 1.4.x to 1.4.49
You must be running an older version of lighttpd. I get ENOENT from gw_backend.c for non-existent path to sockets in lighttpd 1.4.48 on Fedora Linux.
2017-12-11 22:21:00: (gw_backend.c.509) bind failed for: unix:/var/run/a/b/c-0 No such file or directory
I'll be submitting a patch to issue trace to stderr if the path to the error log does not exist.
Updated by gstrauss about 7 years ago
- Status changed from Patch Pending to Fixed
- % Done changed from 0 to 100
Applied in changeset 0c95ed370f49221a9feb33aea3dde9a5aa864c5c.
Updated by joelippa about 7 years ago
I'm currently running lighttpd 1.4.35 on Armbian 5.27 stable Ubuntu 16.04.2 LTS 4.11.1-sun50iw2
Updated by gstrauss about 7 years ago
Please recognize that you're reporting issues in the wrong place. I am sorry to say that Debian and Ubuntu "long term support" releases do a very poor job of tracking lighttpd and taking patches, and you should complain to them on their forums. lighttpd 1.4.35 was released over 3 and 1/2 years ago. There have been 893 commits to lighttpd source since then, and 13 releases. Latest lighttpd release is lighttpd 1.4.48. That's not to say that LTS should take every patch. However, if they are actually "supporting" packages, someone should be evaluating patches and backporting to those releases.
Updated by joelippa about 7 years ago
I guess I should apologise because I do often build from source to run with the latest version of a package and in this case I've not done that. On a positive note I feel we did improve something here that eventually everyone should receive and that wouldn't have happened if I'd taken my issues up with the Ubuntu package maintainers. I'll definitely keep your advice in mind in the future though.
Updated by ememberus almost 6 years ago
A year later, r1.4.45 is still plagued with the same issue - service does not start and the log gives no clue why.
Given the way some maintainers respond, I have no hope this would ever be resolved :(
Sounds to me like it is time to start looking for alternatives.
Updated by gstrauss almost 6 years ago
@ememberus, a fix was provided by us here over a year ago. We don't control your distro of choice, whatever that is.
You're complaining in the wrong place and posting on the wrong board. Go and complain on the forums of your distro of choice.
If your reading comprehension is this poor, yes, please look for other alternatives.
Updated by ememberus almost 6 years ago
Blaming distros, who do not know your tool and have to read same poor error log, is not a fix.
And in no way this could replace proper error logging since only the developer knows what stops service from running.
Updated by stbuehler almost 6 years ago
Fixed in upstream long time ago; nothing to see here.
Also available in: Atom