handling permissions at startup
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.
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)?
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
- 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.
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.
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.
Also available in: Atom