su切换Root变慢解决过程（具体原因尚不明） 兼新人报到

远古山猫

首先报个到，论坛内的各位前辈好。
我学习linux半年了。一直是看着《鸟书》和一些视频，在命令堆中打转，遇到点问题也无法解决，深深感受到这样闭门造车终究难成大器，还是找一个靠谱的社区，多跟业内的前辈学习学习……

远古山猫

      昨天打开虚拟机，陡然发现用 'su -' 切换root用户居然要半分钟，一小时前用着还是正常的……暂且忽略痛苦的过程，总之Google未果（虽然有几个帖子提到，但都没甚结论和解决方案，地址见末尾），问某群无人搭理，最后lz删了/root，尝试从另一虚拟机拷贝/root到本机，居然就解决了，但lz想总不能每次都这么解决吧，还是找出原因比较好，于是……如下：
          （目前仍未找到原因，lz只是通过自己微薄的知识和苦逼的探索锁定了一个突破点，唉，脑力实在不够用啊，还有好多要学。有遇到类似问题的或和我一样的菜鸟可以参考参考，先把问题解决了。最好是社区中能有高手帮忙把原因分析出来。嗯，这句是重点）

-------------------------------------------------------------------分割线--------------------------------------------------------------------------------------------------------

两个前提：1.首先在文本控制台不存在这个问题
              2.切换普通用户亦无此问题

解决方法：拷贝另一系统的/root文件夹（新/root）替换本地的/root（旧/root）
                                                            ----------------->改进版：打包/root，解压到/tmp目录再替换到根目录

       分析：（解决了问题，但仍不知道原因）
                         猜想：1.是/root中的某个配置文件出现问题（可能被更改或误删除了）
                                   解：通过比对原有/root（旧/root）和现有/root（新root），一个个替换，仍找不到错误，
                                      结论1：与/root的文件内容无关
                                   2./root文件夹权限问题
                                   解：将原有/root权限改回550，不能解决，
                                      结论2：与/root的权限无关
                         发现：1.试验：tar解压加入'--no-same-permissions'参数
                                                                      >失败
                                 2.偶然发现：tar打包/root文件夹（旧/root或新的/root均可，这也说明了结论1是对的），解压到/tmp。再拷贝到根目录，均可以解决问题，解压到其他目录再拷贝或直接解压到根目录均不行。
                                                                      ---------- >猜想：/tmp目录较特殊，解压到/tmp下或从/tmp下拷贝会改
                                                                                        变文件的某种属性。

                                                                      ---------- >也许与/tmp的SBIT（粘帖位）有关，试验：
                                                                                          >在/home下建一./tmp目录，权限同/tmp     1777
                                                                                          >解压tar包在此目录下——拷贝，试验再次失败
                                                                                          >结论3：与SBIT无关
                                   
                                   2*."发现2"的补充：
                                       解压在其他路径，再拷贝至/tmp再拷贝到根无效果，必须是解压在/tmp目录才有效果（这时把/tmp/root拷贝到其他任意路径再拷回根目录同样有效），
                                       此时排除'cp -a'的影响可以确定，对结果有影响的是
                                                  <1>.是解压过程
                                                  <2>.与/tmp有关（解压路径）


                                        --------------------->说明解压到/tmp目录和其他目录其结果有些许差别，/tmp的特殊性会影响解压的文件或目录。可能涉及某些隐藏的或特殊的权限——这些权限属性可以影响root用户在图形终端的登录


注：1.以上"拷贝"无特殊说明均为'cp -a'，

-----------------------------------------------万恶的分割线--------------------------------------------------------------------

接开头那段：
       刚刚说道，一小时前还是正常的，那时在学习tar、dump几个工具的使用，倒是有频繁的在/root中删除和拷贝东西，难道是误操作了什么？不管怎样，先Google，网上关于此问题实在是少得可怜，找到的帖子如下：（都是此论坛的）
          http://bbs.chinaunix.net/thread-526085-1-1.html
          http://bbs.chinaunix.net/thread-1963282-1-1.html
          http://bbs.chinaunix.net/thread-4072534-1-1.html
          http://bbs.chinaunix.net/thread-4131421-1-1.html
          http://blog.sina.com.cn/s/blog_69880e320100ytgr.html
几个帖子有说是启动脚本有问题的（加载了费时的东西），有说pam模块（su）有问题的。lz对比过了，真的没问题，而且这几个配置文件的mtime都是好久以前了。
       由于lz怀疑跟/root中的某个文件有关，遂开始了最苦逼的一步，一个个文件或目录替换。最后diff -r ，两文件夹已经完全相同了，奇葩的是，依然是新/root可以保证su正常，旧/root切换慢——尽管文件已经完全一样了……lz彻底崩溃——四个小时就这样白费了……
       然后，如上所言，我偶然发现了 "发现2"，以此为跳板钻研下去，得出如上结论。
       唉！lz累了……只希望能有个结果，不然无法安息啊……

tarchen

不错,实践+总结.