linux重新加载桌面服务

linux重新加载桌面服务步骤如下：

1、启动linux后在终端下输入：startx。

2、进入X11的桌面图形 *** 作模式。

3、修改inittab文件。

4、按i键进入编辑模式，将3改为5，按esc退出编辑，输入：qw保存。

1.检查BIOS设置，确认计算机以正确的顺序加载设备，确保硬盘驱动器被优先加载。

2.检查硬盘驱动器是否工作正常，可以使用硬件测试工具（如硬盘工具箱）来检查是否有硬盘故障。

3.检查硬盘上的引导记录是否损坏，可以使用fdisk命令来检查引导记录的完整性。

4.检查硬盘上的引导记录是否正确，可以使用grub命令来检查硬盘上的引导记录是否正确。

5.检查内核是否正确，可以使用uname命令来检查当前安装的内核是否正确。

6.检查内核参数是否正确，可以使用sysctl命令来检查内核参数是否正确。

7.检查文件系统是否正确，可以使用mount命令来检查文件系统是否正确。

8.检查引导脚本是否正确，可以使用grep命令来检查引导脚本中的内容是否正确。

首先是抓包，步骤如下

在Linux服务器上启动抓包。

从笔记本SSH到Linux服务器，输入用户名并回车。

等待10秒左右，直到登录界面提示输入密码。

停止抓包。

这样就可以得到一个涵盖该现象的网络包了。一般在实验室中没有干扰流量，不用过滤也可以分析，不过我们最好在做实验时就养成过滤的习惯，以适应生产环境中抓到的包。因为我们是通过SSH协议登录的，所以可以直接用“ssh”来过滤，如图所示。SSH包都是加密了的，因此我们看不出每个包代表了什么意思，不过这并不影响分析。从图2中可以看到，21号包和25号包之间恰好就相隔10秒。

这两个包之间所发生的事件，可能就是导致这个现象的原因。于是我再用“frame.number>21 &&frame.number<25”过滤，

分析

从图中可以看到，Linux服务器当时正忙着向DNS服务器查询10.32.200.23的PTR记录（即反向解析），试图获得这个IP地址所对应的域名。该IP属于我们测试所用的笔记本，但由于DNS服务器上没有它的PTR记录，所以两次查询都等了5秒钟还没结果，总共浪费了10秒钟。

我们由此可以推出，这台Linux服务器在收到SSH访问请求时，会先查询该客户端IP所对应的PTR记录。假如经过5秒钟还没有收到回复，就再发一次查询。如果第二次查询还是等了5秒还没回复，就彻底放弃查询。我们甚至可以进一步猜测，如果DNS查询能成功，就不用白等那10秒钟了。

为了验证这个猜测，我在DNS服务器中添加了10.32.200.23的PTR记录，然后再次登录。

这一次果然立即登录进去了。从图的Wireshark截屏可见，DNS查询是成功的，所以21号包和26号包之间几乎是没有时间停顿的。

结果

明白了DNS查询就是问题的起因，接下来就知道怎么进一步研究了。只要在Google搜索“ssh dns”，第一页出来的链接都是关于这个问题的。随便挑几篇阅读一下，就连我这样的Linux初学者都能把这个问题研究透了。原来这个行为是定义在“/etc/ssh/sshd_config”文件中的，默认配置是这样的：

[root@Linux_Server ~]# cat /etc/ssh/sshd_config |grep -i usedns #UseDNS yes

改成下面这样就可以解决了，不用去动DNS服务器上的配置：

[root@Linux_Server~]# cat /etc/ssh/sshd_config |grep -i usedns UseDNS no

---