Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Avoid removing a running driver's PID and socket files if the new driver process fails to initialize #1501

Open
jimklimov opened this issue Jul 17, 2022 · 0 comments
Open

Avoid removing a running driver's PID and socket files if the new driver process fails to initialize #1501

jimklimov opened this issue Jul 17, 2022 · 0 comments
Labels
bug service/daemon start/stop General subject for starting and stopping NUT daemons (drivers, server, monitor); also BG/FG/Debug
Milestone
2.8.3

Comments

@jimklimov
Copy link
Member

Among remaining issues from #1423 to investigate:

Can we jump through some hoops to keep the original driver instance's PID file in place, if a later driver tried to start and failed to initialize? After all, this later driver process dies quickly and the original blocker remains - but now "hidden" for PIDfile lookups...

Originally posted by @jimklimov in #1423 (comment)
@jimklimov jimklimov added bug service/daemon start/stop General subject for starting and stopping NUT daemons (drivers, server, monitor); also BG/FG/Debug labels Jul 17, 2022
@jimklimov jimklimov added this to the 2.8.2 milestone Jul 17, 2022
@jimklimov jimklimov mentioned this issue Jul 17, 2022
Closed
@jimklimov jimklimov modified the milestones: 2.8.2, 2.8.3 Apr 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug service/daemon start/stop General subject for starting and stopping NUT daemons (drivers, server, monitor); also BG/FG/Debug
Projects
None yet
Milestone
2.8.3
Development

No branches or pull requests
1 participant
@jimklimov