On Tue, Mar 26, 2019 at 06:25:07PM +0100, PICCORO McKAY Lenz wrote: > > 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. > > YES i setup some services and when users are acting on those.. data will lose!
This is for typical installations. You can configure most software in a way that turns a normal bug into a data loss issue. Please apply common sense. > * Please specify versions of the following components: > * Debian release in use > > jessie (and later i install strech to test) I'm afraid that jessie is no longer supported. Even stretch won't be updated for such an issue. You're on your own here. Sorry. > * How reliable is the problem? Does it happen every time you restart > lighttpd? > > nop! only after some time waqs passed > and specially if some changes are made to configuration You later indicated that you did not customize the configuration. > * 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? > > i use the command "service lighttpd restart" and seems in some cases > if there are a init script wil be converted on the fly to the "great" systemd > format! If there is a .service file, the init script won't be used. If you manage to use the init script anyway, this is not a bug in the lighttpd package. > * Can you try reproducing the failure in a reduced setting (e.g. set up > a VM with a bare minimal package set)? > > that was a minimal install at VM > was hapened since jessie.. in wheeze does not happened.. It's a bit surprising that nobody ever bothered to report a problem that you categorize as grave for years. In any case, working with such old releases will not move us forward. At this point, only buster and later releases are relevant. Please try reproducing the issue on a buster VM. If you do, please document your steps in detail. Otherwise I will be unable to help you. I still fail to reproduce the reported problem in any way. In principle, stretch could still be fixed via a stable update. If you want to go that route, please provide a patch. I also failed to reproduce the issue on stretch. The present data suggests that the issue only affects non-standard configurations of jessie and stretch. In that case, I won't be working on a solution. If you want to continue, I urge you to provide more details and avoid self-contradictory statements. I also issue a formal warning. Your polemic about init systems is not welcome here. Helmut