On Sun, 2014-07-20 at 12:20 -0400, David A. De Graaf wrote:
On Fri, Jul 18, 2014 at 02:43:41PM -0700, Adam Williamson wrote:
> On Fri, 2014-07-18 at 15:01 -0400, David A. De Graaf wrote:
> > On Fri, Jul 04, 2014 at 12:22:40PM -0700, Adam Williamson wrote:
> > >
> > > System service manipulation
> > >
> > > It must be possible to start, stop, enable and disable system services
> > > using the initialization framework's standard commands.
> >
> > Oh yes, that's perfect.
> >
> > Had this been applied to the most basic Linux command - 'reboot' -
> > we might never have seen Fedora 18, 19, or 20. :-)
>
> Er, how do you mean?
>
> We have a criterion covering reboot functionality already:
>
>
https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Desktop_sh...
>
> though I note there's a funny inconsistency - at Alpha we require
> console-based shutdown to work, at Beta we require graphical shutdown,
> logout and reboot to work, but we never explicitly require console
> logout and reboot to work.
>
> So, let me propose that we amend the beta criterion:
>
> Shutdown, reboot and logout
>
> Shutting down, logging out and rebooting must work using standard
> console commands and the mechanisms offered (if any) by all
> release-blocking desktops.
>
> Thoughts?
Seems more inclusive. I don't understand why the title was
"DESKTOP shutdown, reboot, logout" anyway.
Should have been just "System shutdown, reboot, logout", or better,
just omit the first word modifier altogether, as you propose, Adam.
The reason was that it really did only cover desktops; I think I thought
the console commands were covered at Alpha, but as I noticed when you
brought it up, only shutdown actually is.
My original carp was due to the major aggravation introduced by
systemd - the inability to cleanly 'shutdown' or 'reboot'.
Sometimes these incidents manifested as an interminable delay of
many minutes; other times a complete freeze.
This made the "Magic SysRequest" command set essential -
which should
NEVER be needed.
I believe these failures can all be traced to NFS mounts that could not
be cleanly umounted. But what can be more stupid than waiting for a
non-existent NFS server to respond? Cleanliness is not an option.
I propose that the shutdown++ criterion include prompt
closeout of NFS file systems, requiring perhaps a default
configuration of autofs mounts that will allow quick umounts, despite
unexpected inaccessibility of a remote machine, if this is even
possible. It always worked before systemd.
I think that's going a bit beyond release criterion material personally,
but let's see what others think. Have you filed this as a bug? It would
help to have full details of how the NFS mounts are configured.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net