On Wed, Jul 01, 2020 at 09:16:55PM +0200, Alberto Bursi wrote: > On 01/07/20 17:39, David Sterba wrote: > > On Wed, Jul 01, 2020 at 05:22:18PM +0200, Lukas Straub wrote: > >>> I'm not married to the rescue=onlyfs name, if we can think of something better > >>> I'm good. > >> > >> Maybe you could go a step further and automatically switch to rescue > >> mode if something is corrupt. This is easier for the user than having > >> to remember the mount flags. > > > > We don't want to do the auto-switching in general as it's a non-standard > > situation. It's better to get user attention than to silently mount > > with limited capabilities and then let the user find out that something > > went wrong, eg. system services randomly failing to start or work. > > Eh. I'm sure stopping boot and dropping to initramfs shell is a great > way to get someone's attention. I'm not saying it's pretty and these rescue tasks are only chosing lesser evil. As I understand it, users want a single option to do the magic, aka. fix all problems and continue, but the hard part is how to implement that. The analysis is a necessary step, and it cannot be always automated to the point where autor-repair will not cause more harm than good. > Afaik in mdadm or hardware raid the main way to notify the administrator > of issues is sending an email, or send the error through the server > fleet management software. That's for monitoring tools, I'm not familiar with that topic but seems that hat it could be done. Let's say there's a problem during mount, auto-repair tries something, system boots but is not in ideal state. The status is saved in system log and perhaps in some sysfs file to be grabbed any time later. And the monitoring tools can read that and react (send email).
