今天在写centos7的systemctl 服务是，遇到一个坑，表现为当我执行systemctl命令后shell阻塞在那里，没有像平时执行命令那样自动结束（只能自己按Ctrl+C强制结束），效果如下：
强制结束后，查看程序发现目标程序启动是成功的， 但状态为
activating (start)
而不是
activating (running)
态：
hello.service
服务代码如下:
[Unit]
Description=Hello service
[Service]
Type=forking
User=root
Group=root
ExecStart=/usr/bin/python /root/hello.py
Restart=always
[Install]
WantedBy=multi-user.target
hello.py
代码为:
#coding:utf-8
import time
while True:
time.sleep(5)
解决方法：
导致此问题的原因是：hello.service类型选择有问题, 不应该选forking类型；类型改为Type=simple（或删除Type=forking这句），问题便得到解决。
出现这个问题的可能原因，先看看type的种类和解释：
| Type=oneshot | 这一选项适用于只执行一项任务、随后立即退出的服务。可能需要同时设置 RemainAfterExit=yes 使得 systemd 在服务进程退出之后仍然认为服务处于激活状态。 |
| Type=notify |
与 Type=simple 相同，但约定服务会在就绪后向 systemd 发送一个信号。这一通知的实现由 libsystemd-daemon.so 提供。
|
| Type=dbus | 若以此方式启动，当指定的 BusName 出现在DBus系统总线上时，systemd认为服务就绪。 |
| Type=idle | systemd会等待所有任务处理完成后，才开始执行 idle 类型的单元。其他行为与 Type=simple 类似。 |
| Type=forking | systemd认为当该服务进程fork，且父进程退出后服务启动成功。对于常规的守护进程（daemon），除非你确定此启动方式无法满足需求，使用此类型启动即可。使用此启动类型应同时指定 PIDFile=，以便 systemd 能够跟踪服务的主进程 |
| Type=simple | （默认值） systemd认为该服务将立即启动。服务进程不会 fork 。如果该服务要启动其他服务，不要使用此类型启动，除非该服务是socket 激活型。 |
从上表可以看到，当类型为forking时，systemd会认为所运行当该服务本身是守护进程即本身会fork，且只有父进程退出后systemd才会退出，但由于参考例子并不是守护进程，故systemd一直处于阻塞等待状态，默认的simple无等待这一环节。
问题：今天在写centos7的systemctl 服务是，遇到一个坑，表现为当我执行systemctl命令后shell阻塞在那里，没有像平时执行命令那样自动结束（只能自己按Ctrl+C强制结束），效果如下：强制结束后，查看程序发现目标程序启动是成功的， 但状态为activating (start)而不是activating (running)态：hello.service服务代码如下:[Unit]...
在linux内核启动完以后，会执行/etc/rc.d/rc.local脚本，最后再执行/bin/login程序，进入用户登陆界面
传统的做法，如果要在linux里添加开机自启的命令，需要在/etc/rc.d/rc.local脚本中添加
由于init进程是串行启动的，rc.local脚本会在所有其他服务启动完之后执行
而systemd是并行执行的，centos7及以后已弃用该脚本，如需使用该脚本需要手动赋予可执行权限。
systemd取代了initd，成为内核加载完以后系统启动的第一个进程(PID为1)，其他
解决错误Failed to get D-Bus connection: Operation not permiited（WSL+Centos7错误）
mv /usr/bin/systemctl /usr/bin/systemctl.old #备份旧文件
cp systemctl /usr/bin/systemctl #替换
chmod +x /usr/bin/systemctl #给执行权限
net stop LxssManager #停止LxssManager服务
net start LxssManager #启动LxssManager服务
文件来源地址：https://raw.githubusercontent.com/gdraheim/docker-systemctl-replacement/master/files/docker/systemctl.py
在CentOS7上安装ftp服务器用于保存服务端上传的图片。
1、CentOS卸载vsftpd的方法
如果服务器上已经安装了vsftpd服务，配置出错需要卸载vsftpd服务。
1.1 查找vsftpd服务
[root@localhost /]# rpm -aq vsftpd
返回结果显示：
vsftpd-3.0.2-21.el7.x86_64 #此处是查找vsftpd的返回结果
表示此服务期之前已经安装过vsftpd服务。
1.2 删除查找到的vsftpd服务
注：在卸载vsftpd之前，先停止vsftpd
[root@localhost /]# /sbin/service vsftpd
CentOS 5使用SysV init；CentOS 6使用Upstart，CentOS 7使用Systemd管理守护进程。centos7采用 systemd管理，服务独立的运行在内存中，服务响应速度快，但占用更多内存。独立服务的服务启动脚本都在目录 /usr/lib/systemd/system里。Systend的新特性：
- 系统引导时实现服务的并行启动；
- 按需激活进程；
- 系统实现快照；
- 基于依赖关系定义服务的控制逻辑；...............
最近发现mongodb总是莫名其妙的挂掉，一边查找原因，一边想着如果能自动重启就好了，于是mongodb的自动重启这件事就提上日程了。本来以为最多半小时的事，没想到还是遇到了一些奇妙的问题，为了找原因花费了不少时间。在这里记录一下，以便其他同学避免踩坑。
踩坑历程再现
操作系统：Ubuntu 18.04
建立了一个/lib/systemd/system/mongo.service文件，在文件上写上对应内容
[Unit]
Description=mongodb
After=network.target
一般情况下系统进不去会分为好多种 1、人为修改权限错误导致root权限丢失 2、服务器中毒导致权限被篡改root权限和普通用户均无法登陆更恶劣点的接显示器后都无法登陆系统，在此我们需要具体查明是什么原因导致
正常的排查方法如下：
1.首先需要查明ssh的配置文件有无问题
cat /etc/ssh/sshd_config
观察一下两个信息是否正确
#Permit
CentOS 7的服务systemctl脚本存放在：/usr/lib/systemd/，有系统（system）和用户（user）之分，需要开机不登陆就能运行的程序，存在系统服务里，即：/usr/lib/systemd/system目录下
每一个服务以.service结尾，一般会分为3部分：[Unit]、[Service]和[Install]，我写的这个服务用于开机运行tomcat项目:
1. 打开终端，使用命令 `vim` 或者其他文本编辑器新建一个文件，例如 `myscript.sh`。
2. 在文件的第一行添加 `#!/bin/bash`，这是告诉系统要使用 bash 解释器来执行脚本。
3. 在接下来的行中编写 shell 脚本的命令，例如创建变量、判断条件、循环语句等等。
4. 保存文件并退出编辑器。
5. 在终端中使用 `chmod +x myscript.sh` 命令将脚本文件变为可执行文件。
6. 使用 `./myscript.sh` 命令执行脚本文件。
这些步骤可以让您在 CentOS 7 上编写和执行 shell 脚本。
