[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#925478: restart action breaks with systemd (Again)



Control: severity -1 important
Control: tags -1 + unreproducible moreinfo

Thank you for the report.

On Mon, Mar 25, 2019 at 12:18:02PM -0400, PICCORO McKAY Lenz wrote:
> Package: lighttpd
> Version: 1.4.35-4+deb8u1
> Version: 1.4.53-3

You are listing two versions here. Does it really affect both versions?

> Severity: grave

Please use appropriate severity levels. `grave' is reserved for data
loss, security holes are issues that make the package entirely unusable
by anyone. Refer to https://www.debian.org/Bugs/Developer#severities for
a more detailed explanation.

> The systemd (again) seems have problems iwth lighttpd..
> when i try to restart the service aftyer some time.. service does not start
> and a paralele service are in backgound..
> 
> that problem does not happen with wheeze , neither happen in Devuan
> that used sysv-init
> 
> until that days, systemd seems are mor a pain in the ass rather a solution!

I appreciate your help with reporting a bug. The additional polemic is
not constructive though. Please stop that.

> root@ip-10-101-2-11:/etc/# service lighttpd status
> ● lighttpd.service - Lighttpd Daemon
>    Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled)
>    Active: failed (Result: exit-code) since Mon 2019-03-25 16:08:05 UTC; 4s ago
>   Process: 3019 ExecStart=/usr/sbin/lighttpd -D -f
> /etc/lighttpd/lighttpd.conf (code=exited, status=255)
>   Process: 3011 ExecStartPre=/usr/sbin/lighttpd -t -f
> /etc/lighttpd/lighttpd.conf (code=exited, status=0/SUCCESS)
>  Main PID: 3019 (code=exited, status=255)
> 
> Mar 25 16:08:05 ip-10-101-2-11 lighttpd[3011]: Syntax OK
> Mar 25 16:08:05 ip-10-101-2-11 systemd[1]: Started Lighttpd Daemon.
> Mar 25 16:08:05 ip-10-101-2-11 lighttpd[3019]: 2019-03-25 16:08:05:
> (network.c.409) can't bind to port:  80 Addre...n use
> Mar 25 16:08:05 ip-10-101-2-11 systemd[1]: lighttpd.service: main
> process exited, code=exited, status=255/n/a
> Mar 25 16:08:05 ip-10-101-2-11 systemd[1]: Unit lighttpd.service
> entered failed state.
> Hint: Some lines were ellipsized, use -l to show in full.
> root@ip-10-101-2-11:/etc/# ps -lxa | grep http
> 0     0  3032 32390  20   0  12728  2188 -      S+   pts/1      0:00
> grep --color=auto http
> 1    33 20456     1  20   0  97324  2284 -      S    ?          0:17
> /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf

                    ^^^ (see below)

> root@ip-10-101-2-11:/etc/# kill -9 20456
> root@ip-10-101-2-11:/etc/# service lighttpd start
> root@ip-10-101-2-11:/etc/# service lighttpd status
> ● lighttpd.service - Lighttpd Daemon
>    Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled)
>    Active: active (running) since Mon 2019-03-25 16:08:52 UTC; 11s ago
>   Process: 3050 ExecStartPre=/usr/sbin/lighttpd -t -f
> /etc/lighttpd/lighttpd.conf (code=exited, status=0/SUCCESS)
>  Main PID: 3058 (lighttpd)
>    CGroup: /system.slice/lighttpd.service
>            └─3058 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf
> 
> Mar 25 16:08:52 ip-10-101-2-11 lighttpd[3050]: Syntax OK
> Mar 25 16:08:52 ip-10-101-2-11 systemd[1]: Started Lighttpd Daemon.
> Mar 25 16:08:58 ip-10-101-2-11 systemd[1]: Started Lighttpd Daemon.
> root@ip-10-101-2-11:/etc/#

I attempted reproducing this bug on a Debian buster system. After
restarting lighttpd twenty times, I was not able to reproduce it in a
single occasion. This does not imply absence of the bug, just that we
need more information.

Please answer the following questions and remove the moreinfo tag when
doing so:

 * Please specify versions of the following components:
   * Debian release in use
   * systemd
   * lighttpd
 * How reliable is the problem? Does it happen every time you restart
   lighttpd?
 * In your log I marked the spot where lighttpd occurs in the process
   list. Notably, it lacks the -D flag, but the .service file supplies
   -D. Are you sure that this process is created by the .service file?
 * Did you customize the configuration or the .service file? Can you be
   specific about notable adjustments?
 * Can you try reproducing the failure in a reduced setting (e.g. set up
   a VM with a bare minimal package set)?

Helmut


Reply to: