Summary: | net-wireless/hostapd-2.6-r1 - When PID file is missing hostapd won't restart | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Xander <xander> |
Component: | Current packages | Assignee: | Andriy Utkin (RETIRED) <andrey_utkin> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 652716 | ||
Bug Blocks: |
Description
Xander
2018-02-01 07:31:38 UTC
Will look into the ticket soon. Have not read it yet. This is an openrc issue, however it can be worked arount at hostapd init script level if needed. I've also noticed this issue in the past, and not just with hostapd I think. I've talked a bit on #openrc about this. The fact that hostapd removes pidfile on termination is considered legit, so I proposed a patch https://gist.github.com/andrey-utkin/cf3fd47aeacf6dd0657d18e1811dd72f . dwfreed said he's thinking of a different way to fix it. So please hang on a bit more. With future release of openrc 0.36, this will be fixed. I haven't reverted your change, but I wanted to bring this back up because there might be a better fix. The "zap" command can be used to reset a daemon which has crashed to the stopped state. The restart command is currently the equivalent of "stop" followed by "start". Would it be better if the restart command ran "stop" then "zap" then "start"? (In reply to William Hubbs from comment #4) > I haven't reverted your change, but I wanted to bring this back up > because there might be a better fix. So that when a better fix comes, the current one will be reverted? > The "zap" command can be used to reset a daemon which has crashed to the > stopped state. True, however AFAIK "zap" is a unique OpenRC/Gentoo thing so it takes newcomers/foreigners some mental effort to learn to operate this concept. I actually never liked to use it :) > The restart command is currently the equivalent of "stop" followed by > "start". > Would it be better if the restart command ran "stop" then "zap" then > "start"? I am frowny about this because this (restart by default is stop followed by start) is a documented fundamental thing, so changing this complicates beginner level docs. So, are you going to make just pure "stop" operation return failure? Or will you make it always do implicit "zap" after the stopping operation? Practical example: I do "openrc single && kexec -e" to reboot a server quickly after kernel upgrade. "openrc single" basically stops a bunch of services. Will "openrc single" fail if it encounters described situation in one of services? If yes, then this is an undesirable effect for me. Sorry for a bit messy text, typed in a bit of hurry, hope it makes some sense to you. Please move discussion to the OpenRC bug I reopened instead, bug #652716. Closing for now. The openrc fix hasn't been reverted, so things should work as requested by reporter in future. If that fix gets reverted, which is deemed possible, then, in the worst case, the resolution will be for reporter to stick with doing "rc-service hostapd zap" before "... start" and just deal with it. |