使用 wifi 并存在 nfs 挂接时无法关机

这个问题非常简单,

13.1(64位)+GNOME的重现方式:

  1. 启动电脑,插上网钱,在命令行†挂一个NFS点到/mnt/上。

  2. 关机(不必进入或使用/mnt/)

  3. 关机正常。

  4. 启动电脑,不插网线。这时桌面右上角有WIFI图标显示WIFI已经连接。

  5. 在命令行†挂一个NFS点到/mnt/上。

  6. 关机。

  7. 画面淡出,桌面背景淡成灰色,然后一直是这样的灰色。

印象07、08年那时候,也是OPENSUSE,试过如果这样放一个星期左右,机器最终还是会关的。这次只试着放了一个晚上,一直关不掉。

又:

  1. CTRL+ALT+F1调不出VIRTUAL CONSOLE。
  2. 用CTRL+ALT+SYSRQ+(Raise Skinny Elephant Is Utterly Boring重启字决可以重启)。

有什么办法可以解决或绕开?

†所用命令行是:

> sudo mount laputa:/var/local /mnt/
root's password:
Starting rpc.statd ...                                               done

对这种情况,最快的回答是大家都不是这样干的:Mac OS和Windows不是这样设计的(修正¹),iOS及Android亦不是,Ubuntu也不是,这些产品在移动化设计上使用量均大于SuSE。但是这样简单地拿别的产品来压,没诚意也不讲道理。下面是道理:

  1. :Windows 7经测试表现跟SUSE一样,以前没注意到是因为其NFS自动umount是工作正常的,注:Windows 7确实提供了选件mount命令用于挂NFS,它能正常关机,LINUX上的更应该能做到了。

Windows上确实有为了满足企业计算需求而特别制做的WIFI连接组件,过去单位上有用过,其名字我忘了,好像是Think VANTAGE管理套件的一部分,这一部分的名字好像是access conncetion企业管理组件之类--也就是说他们不把这个当做基本需求,而是当做一个adVANTAGE来做到附加产品里。相应地,在用户没有登录时就利用WIFI检查电子邮件、同步存贮云或下载更新系统包也是能提供方便的设计,我有时候也会从妻子的UBUNTU电脑上拷贝文件(nautilus支持sftp)而她还没起床登录电脑呢,更牛逼的是XDMCP本来就是在没登录时可用的,这样笔电跑不动的GNU R我可以用台式机的(我有分析股票价格历史用它),可惜ubuntu已经把XDMCP弄坏了我就放弃这种小小方便了。哪些需求做成built-in哪些做成plug-in是一个经典设计问题,就我们正在讨论的事,我相信网上某个地方已经讨论了很多,这里不想直接得出结论哪种设计合理,但是更想提我观察到的一个现象:

我不是来踢suse的馆,事实是SUSE有您这样愿意帮助的开发者真的对扩大SUSE用户群多样性很好,因为明知我们不是商用客户还有兴趣讨论用户需求。我只是想借这个机会说上述的思维游戏,对开拓市场的人也许很有用。

对我而言,不必WIFI在末登录时可用,只要有办法不经过手动umount可以正常关机,我就已经十分满意了。比如说,能不能像gnome-session-property一样在某个地方加一行指令,关机断网前执行之就可以了。

考虑我的应用场景,我没有做umount NFS,因为指望着笔记本关机时系统自动UMOUNT所有网络文件共享服务。

如果手动,这个问题也应该可以重现,只要在GNOME里登出用户,然后用CTRL+ALT+F1进入VIRTUAL CONSOLE,在里面UMOUNT,就应该观察到失败。另外,不一定只要断网NFS就应该自动载掉,NFS是设计成能自动恢复的,如果主机睡眠,网掉了NFS不应该解开,即使NFS上放了一半的电影,主机醒来时也可以接着放,这个是检验过的,我有时候就会这样用(UBUNTU)。

你看到我给出手动mount,可能会问既然手动挂了为何不手动umount。答案是如果umount可以自动,我就可以用autofs把挂接的事也自动,我有现成的autofs配置,就那几行用了几年的。家用环境每次看电影前都手动mount一下不方便。

我想起有一种应用场景不得不考虑,就是私人的 WIFI 密码。在有些情况下,尤其是企业用户,个人是使用自己的公司账户用户名 / 密码登录公司 WIFI,通过后端账户服务进行验证,而不是公司统一配置同样的 WIFI 密码。在这种情况下,没有登录就连接 WIFI 的方式不可用,更不安全。

其实我个人认为所谓系统级和用户级,只是一种选择,无论那种方式都不可能照顾到所有的应用场景。所以需要更强的变通性,比如 ** 如何在用户 Logout 之前自动运行 umount 脚本 ** 。

其实这个是企业产品策略问题,SUSE 这样的公司更偏向于以用户 (指的是企业用户) 需求为导向的产品开发策略。也就是根据用户的需求,或者用户潜在的需求制定研发方向。这注定了在产品上更偏向于稳定性,同时研发的人员的数量也相对较少。但是也并不代表产品缺乏新的特性,只是这些新引入的特性没有放在适应系统级还是用户级 WIFI 这样的方向上。和上面回复说的一样,研发策略也是无法兼顾的问题,只在于选择。

另外关于 BBC,认为 Linux 占比少,指的应该是 Linux 在操作系统市场中所占的比例,所以也许是基于成本考虑作出以上决策。你不能指望一家企业通过自己的一个产品把整个桌面平台的市场份额拉升到一个相当的高度。其实也是" 鸡下蛋,蛋生鸡" 的问题,Linux 平台占有率低所以没有人做上面的产品,而缺乏产品又导致 Linux 占有率低。要打破这个循环,不能单方面寄希望于让企业开发 Linux 平台产品这一点。

晚上没睡着,继续看贴子。你说的办法能做到最好,只是有一个问题是logout之前umount是否技术上可能做到。我印象哪怕是这种情况都会引起umount失败:gedit保存文件到NFS上,然后gedit关闭掉,这时候NFS就已经不能umount了,因为gtk记住了最近使用的十个文件,预备着有人使用文件打开对话框时候显示这最近十个文件的图标,为此保持了对十个文件或文件夹的访问,这样就挂住了NFS使用。如果suse的设计是先退出gnome-session,完全不再用这十个文件了,再断网,那么两步中间还有机会加入umount命令,如果是先断网再退出gnome,那就只有使用lazy umoun(umount -l)了,而老使用lazy umount不知道好不好。十分期待提出各种解决或绕开的办法。

找到当年看的新闻了:

不过这是当年旧闻,现在BBC已经向Linux用户的需求迁就了,现在已经有LINUX版了。

lazy umount 不知道会有什么后遗症,可以测试评估一下。你说的记住最近使用的十个文件,应该是 nautilus 干的吧?如果是这样,可以讨论一下如何在 umount 之前通过某种机制取消 nautilus 的所有记忆。

又是一次艰苦熬夜之后,这个问题竟然解决了。(真是年纪大了,现在不怎么会熬夜了.) 其实这个问题早在系统中有相应办法:

  1. 在右上角打开 WIFI Settings
  2. 选中当前连接的网络,选择修改
  3. 在 Identity 中,最后一个选项是 Make avaliable to other users,选中它,这样登出用户时就不会断网。实测系统 umount 也正常了。

其实这个选项我知道,因为 Ubuntu 里就有,并且我在 OpenSUSE 里专门找过此选项,没有找到是因为 Ubuntu 里是编辑 WIFI 时的第一个打开的选项卡 General 里的内容,并且默认是选中的;OpenSUSE 里是放在 Identity 这个子选项卡中,而它前面是 Secutiry 选项卡。这个功能我怎样想都觉得应该算是安全部分,所以老在 Security 部分找,Identity 我想当然地认为是 ESSID 重名时按 SSID 选网用的。

要说也是易用性设计的问题,设计师怎会想到选项换一个地方就让老夫忙忽死--总之一晚上都在用各种方式破解,浪费了不少时间,气绥时回到 WIFI-Settings 对话框,又仔细看了每个选项卡才找到。但是总算解决了。下面的任务就是 挽起袖子解决五笔输入的问题 ](Ibus-engine-table 没有运行,无法添加 ibus-table-* 输入法) 了。

有心人可以帮助把这个问题提交一下,比如把这个选项不默认打开也要放在 SECURITY 部分。我不再提交易用性 BUG 了,因为过去几年在开源软件中提交过不少,尤其是改词改术语方便使用的,比如“右边选项会影响左边的选择,不合用户先选左后选右的习惯,建议左右换过来”,“reject 是个动词,暗示用户照片已经被处理,不用再管,其实只是做了标记,仍然占硬盘空间并且清理回收站时不能回收,用户会积累大量这样的照片占地方,所以 reject 名实不符,应该改名,比如 mark as rejected 俾使用户知道照片没有也不会被自动删除”,“语言栏这个名字暗示这是切换或管理语言的,其实里面一般只是中文的多个输入法,而另外还专门有一个通知栏图标真的管语言切换,很乱,现有语言栏应该改名叫输入法栏”,“文件比较器的 left hand files 应该列在左边,right hand files 应该列在右边,现在是位置一上一下而命名一左一右,用户很困惑”,这类 BUG 从来没获接受过,甚至很少有人在上面留言,也不会被拒绝,而是直接没人理,故现在已经不太愿意提了。(倒是我提交的 bug 谈到硬伤如 crash 的会被激烈讨论和接受。)

这是因为优先级的问题,crash 的优先级肯定是比界面易用性 BUG 的优先级高,所以就要求最快解决,尤其是在人力资源有限的情况下。另外界面易用性 BUG 还有一个问题,就是不同的人看法不一样,使用习惯不同。这就不像 crash 这种 bug,如果一个程序 crash 了,那就是 crash 了,很明白的摆在面前。

从使得任务失败的角度看,crash 不一定比易用性问题优先级高。比如给一个用户,请他发电子邮件给 david,结果是因为 crash 了还是因为功能找不到放弃了,都算失败。crash 的优点就是它明显是程序的问题,而易用性问题可以被描述成用户的问题。但是我觉得如果把用户也算在整合大系统里,用户的问题也算系统失败,用户 crash 也应该算系统 crash,假如用户使用完系统,觉得垂头丧气,生活没意义、有严重失败感、丧失性功能、得抑郁症,算不算用户 crash 了?一笑。有很多易用性问题,只要界面上改个词,就可以解决人机组合系统的 crash。不过大话题无法谈,就这样结束吧。