Project

General

Profile

Feature #2847

handling permissions at startup

Added by joelippa 6 months ago. Updated 6 months ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
core
Target version:
Start date:
2017-12-10
Due date:
% Done:

100%

Estimated time:
Missing in 1.5.x:

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.

Associated revisions

Revision 0c95ed37 (diff)
Added by gstrauss 6 months ago

[core] report to stderr if errorlog path ENOENT (fixes #2847)

x-ref:
"handling permissions at startup"
https://redmine.lighttpd.net/issues/2847

History

#1

Updated by stbuehler 6 months 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)?

#2

Updated by joelippa 6 months 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
#3

Updated by stbuehler 6 months ago

The debian package has /usr/lib/tmpfiles.d/lighttpd.tmpfile.conf which should at least ensure the presence of /var/run/lighttpd.

#4

Updated by gstrauss 6 months 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.

#5

Updated by gstrauss 6 months 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.

#6

Updated by gstrauss 6 months ago

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

Updated by gstrauss 6 months ago

  • Category set to core
#8

Updated by joelippa 6 months ago

I'm currently running lighttpd 1.4.35 on Armbian 5.27 stable Ubuntu 16.04.2 LTS 4.11.1-sun50iw2

#9

Updated by gstrauss 6 months 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.

#10

Updated by joelippa 6 months 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.

Also available in: Atom