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.

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

Allow GUI to stop daemon when status is "should be stopped" #1562 #70

Closed

Conversation

candlerb
Copy link
Contributor

If a daemon is running but the status is "should be stopped", then we should
still render the stop button in the GUI

…nc#1562

If a daemon is running but the status is "should be stopped", then we should
still render the stop button in the GUI
@fgaudreault
Copy link

If the service is started when it should in theory be offline, the problem is elsewhere.

Exemple, if you change the config, say named -> disabled (from enabled), and you restart PF, the service will not be stopped at first place. So named will continue running even if "it should be stopped". Is this patch fixing this?

@candlerb
Copy link
Contributor Author

candlerb commented Oct 8, 2012

You are correct: if you configure services.named -> disabled followed by /etc/init.d/packetfence restart, then it remains running. Ditto for "pfcmd service pf restart". However, "pfcmd service named stop" does stop it.

I'd say this is a related but different problem. With this patch you can at least stop the service through the GUI (because the GUI lets you do "pfcmd service named stop")

Possible approaches for the second problem:

  • 'pf stop' should apply to @pf::services::ALL_SERVICES
  • 'pf stop' should apply to @alreadyRunningServices (borrowing logic from 'start')
  • 'pf stop' should apply to the union of @services and @alreadyRunningServices

Which do you prefer?

@cgx cgx closed this May 31, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants