| Anonymous | Login | 2024-05-02 13:56 MDT |
| Main | My View | View Issues | Change Log | Roadmap | Repositories |
| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0001579 | ClearOS | app-base - Base System | public | 2014-02-20 07:58 | 2014-02-20 08:42 | ||||
| Reporter | bchambers | ||||||||
| Assigned To | bchambers | ||||||||
| Priority | normal | Severity | minor | Reproducibility | have not tried | ||||
| Status | closed | Resolution | won't fix | ||||||
| Platform | OS | OS Version | |||||||
| Product Version | 6.5.0 | ||||||||
| Target Version | 6.5.0 Updates | Fixed in Version | |||||||
| Summary | 0001579: Sometimes impossible to start services from Webconfig | ||||||||
| Description | Services aren't perfect and sometimes exit uncleanly. For example: # /etc/rc.d/init.d/ipsec status IPsec stopped but... has subsystem lock (/var/lock/subsys/ipsec)! In this case, it is impossible to start the service via Webconfig. Simply stopping the service using init scripts cleans up the lock files and the service starts. Webconfig's Daemon should stop a service before starting if it is in the stopped state as a pro-active resolution to this type of issue. No harm in doing so...and it may prevent user frustration in this type of scenario (eg. they will never see/know of the orphaned lock file) except in the log file. | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files | |||||||||
 Relationships |
||||||
|
||||||
 Relationships |
|
Notes |
|
|
(0001146) user2 2014-02-20 08:04 |
I think this was already done... checking. |
|
(0001147) user2 2014-02-20 08:06 |
The start/stop daemon widget behaves this way - 0001239 The Daemon API should stay as-is, but perhaps the "Services" app needs to be changed? |
|
(0001148) bchambers (administrator) 2014-02-20 08:26 |
Running app-base-1.5.23-1 No mention of stopping service first in the 'set_running_state' function: public function set_running_state($state) { clearos_profile(__METHOD__, __LINE__); Validation_Exception::is_valid($this->validate_state($state)); if (! $this->is_installed()) throw new Engine_Exception(lang('base_not_installed')); $is_running = $this->get_running_state(); if ($is_running && $state) { // issued start on already running daemon return; } else if (!$is_running && !$state) { // issued stop on already stopped daemon return; } $args = ($state) ? 'start' : 'stop'; $options['stdin'] = "use_popen"; $shell = new Shell(); $shell->execute(self::COMMAND_SERVICE, "$this->initscript $args", TRUE, $options); } |
|
(0001149) bchambers (administrator) 2014-02-20 08:32 |
Ah...in the controller...I see. Hmmm...wonder why it did not work. I was starting Ipsec from the Dynamic VPN page. <lightbulb>This was trying to start the vpnwatch daemon, not IPsec</lightbulb> Sorry! Hmm...wonder why vpnwatchd wasn't starting ;-) |
|
(0001150) user2 2014-02-20 08:42 |
The change in 0001239 is done in the widget/controller (controllers/daemon.php), so apps using that standard stop/start button in webconfig should already be doing a "stop" before a start. Perhaps that's broken? The set_running_state() method should behave the same way as the system IMHO. I have no objection with adding a flag to that method though. |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2014-02-20 07:58 | bchambers | New Issue | |
| 2014-02-20 07:58 | bchambers | Status | new => assigned |
| 2014-02-20 07:58 | bchambers | Assigned To | => bchambers |
| 2014-02-20 08:04 | user2 | Note Added: 0001146 | |
| 2014-02-20 08:05 | user2 | Relationship added | related to 0001239 |
| 2014-02-20 08:06 | user2 | Note Added: 0001147 | |
| 2014-02-20 08:26 | bchambers | Note Added: 0001148 | |
| 2014-02-20 08:32 | bchambers | Note Added: 0001149 | |
| 2014-02-20 08:33 | bchambers | Status | assigned => closed |
| 2014-02-20 08:33 | bchambers | Resolution | open => won't fix |
| 2014-02-20 08:42 | user2 | Note Added: 0001150 | |
|
Issue History |