Opened 19 months ago
Last modified 19 months ago
#989 new defect
notifier 'restart' hammer needs fixing
| Reported by: | gcooper | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | Backend | Version: | 8.0.2-RELEASE |
| Keywords: | Cc: |
Description
Today, when someone toggles a service via the GUI it restarts the service:
else:
started = notifier().restart(changing_service)
This is not intelligent by any means as it increases the likelihood of service startup failure, and it adds to the service startup / teardown time unnecessarily, and quite frankly makes FreeNAS look like a slow solution to many users.
Change History (3)
comment:1 follow-up: ↓ 2 Changed 19 months ago by delphij
comment:2 in reply to: ↑ 1 ; follow-up: ↓ 3 Changed 19 months ago by gcooper
Replying to delphij:
What's your proposed solution?
- Implement start and stop analogs in notifier.
- Don't explicitly call restart in the GUI.
- Merge the AD and LDAP special cases into the more general case in the GUI code.
Replying to delphij:
And would you mind explain a little bit more about why this would increase the likelihood of startup failures and/or slow down startup/teardown, by what percentage?
We use the force-verbs in many of the startup / teardown operations because we don't use / print out the rc(8) vars in /etc/rc.conf, or elsewhere for many of the services we start, which means that we're assuming that we know how to start stuff up better than the ports maintainer does, and we're willing to eat the consequences if things fail later on down the line. This also means that we're explicitly starting and stopping services unnecessarily, which means that it executes a lot more stuff in the start and stop functions unnecessarily (samba for instance), which can go and whack things that it isn't supposed to.
I don't have raw statistics to back up my claims. I just know provided experience that starting and stopping services via force verbs is ugly and error prone -- in particular after I had to go in and fix the netatalk stuff on trunk (r8380) to actually start and stop appropriately (dbus + avahi + netatalk).
comment:3 in reply to: ↑ 2 Changed 19 months ago by delphij
Replying to gcooper:
Replying to delphij:
What's your proposed solution?
- Implement start and stop analogs in notifier.
Like?
- Don't explicitly call restart in the GUI.
In order to implement this we will have to either implement a forcestop verb, or do the stop/start in two stages.
- Make the special cases for AD and LDAP the more general case in the GUI code.
The startup and stop of AD and LDAP needs to be fixed in my opinion, e.g. current code wants to sleep for 5 to 10 seconds. Some of the sleeps are needed so concurrent startup of daemons won't conflict with each other, but is better done in a more clean way.
Replying to delphij:
And would you mind explain a little bit more about why this would increase the likelihood of startup failures and/or slow down startup/teardown, by what percentage?
We use the force-verbs in many of the startup / teardown operations because we don't use / print out the rc(8) vars in /etc/rc.conf, or elsewhere for many of the services we start, which means that we're assuming that we know how to start stuff up better than the ports maintainer does, and we're willing to eat the consequences if things fail later on down the line. This also means that we're explicitly starting and stopping services unnecessarily, which means that it executes a lot more stuff in the start and stop functions unnecessarily (samba for instance), which can go and whack things that it isn't supposed to.
We only use force-verbs when stopping, because in the old rc.subr code the system will not stop daemons when foo_enable="NO". As far as I know we NEVER used a single forcestart in the whole GUI.
I don't have raw statistics to back up my claims. I just know provided experience that starting and stopping services via force verbs is ugly and error prone -- in particular after I had to go in and fix the netatalk stuff on trunk (r8380) to actually start and stop appropriately (dbus + avahi + netatalk).
It was you broke the thing in r8173 and fixed it in a different (and wrong in my opinion, because the start/stop methods of netatalk needs to be fixed and fed back upstream instead) way.

What's your proposed solution? And would you mind explain a little bit more about why this would increase the likelihood of startup failures and/or slow down startup/teardown, by what percentage?