Summary: | sys-apps/openrc savecache/mount-ro interaction | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Duncan <1i5t5.duncan> |
Component: | [OLD] baselayout | Assignee: | OpenRC Team <openrc> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jmbsvicetto, roy |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Duncan
2011-02-25 09:36:33 UTC
Roy, Can you give me your advice on this bug? Commit 3d3700 sets up the savecache service so that it warns about clock skews. However, it also sets things up so that a clock skew causes the cache to not be saved and causes the savecache service to return failure by default. Should the savecache service return a failure in this situation? Also, I see that there is a variable set up so that the user could configure whether or not the cache is saved if the clock is skewed, but the variable itself is not set to a default value in /etc/conf.d/savecache, and there is no documentation for it anywhere. Should we set up a /etc/conf.d/savecache and document this feature, or make the service always save the cache? It's a two fold problem 1) I firmly believe that if a service fails, it should return a failure 2) Some services need to stay up if a dependant fails stop but equally some services need to go down in a critical state like so. Now, this is only a *real* problem when it critical that the system moves from one state to another (up -> shutdown). It's a pain moving from default -> foo, but not (or should not be) critical. I would add a toggle to each runlevel allowing it to ignore failed services at stop so that others can continue. (In reply to comment #2) > It's a two fold problem > 1) I firmly believe that if a service fails, it should return a failure > 2) Some services need to stay up if a dependant fails stop but equally some > services need to go down in a critical state like so. > Now, this is only a *real* problem when it critical that the system moves from > one state to another (up -> shutdown). It's a pain moving from default -> foo, > but not (or should not be) critical. > I would add a toggle to each runlevel allowing it to ignore failed services at > stop so that others can continue. I'm not sure I'm following you. The issue here isn't to do with stopping services, but starting them. mount-ro's depend function has: need killprocs savecache Killprocs always returns success, so there isn't an issue with it. Savecache though, returns failure if it doesn't save the cache due to clock skew, and if that happens, mount-ro doesn't get executed because it has a need dependency on savecache, and this could be a bad situation during shutdown. If you look at line 11 of savecache.in, whether or not it returns a failure is controlled by a conditional that will never be false. Here are my questions: 1) Why do we have a conditional that is never false? Were you going to make that user configurable at some point? 2) Is the need dependency in mount-ro too strong for this situation? Should it possibly be after instead? I spoke with our base-system lead about this, and the approach we came up with was to have savecache always report success when the system is in the process of shutting down. I implemented this in git, commit 8730248. |