杀掉一个系统的守护进程挺容易的，是吗？真的吗？
如果你的守护进程就有一个单个进程，杀掉它是挺容易的。你键入killall rsyslogd，然后syslog守护进程远去了。然而这种方法有点脏：它杀死所有以syslog命名的进程，包括某个倒霉用户碰巧用户名叫syslog。好点的方法是读.pid文件，像这样kill `cat /var/run/syslogd.pid`。前进了一步，但这真是我们要的吗？
更多情况下它不是我们想要的。考虑下像Aapche，crond，或者atd这样的服务，它们的一项操作就是产生子进程。用户任意配置子进程，比如cron，或者作业，甚至整个的应用服务器。如果你杀掉apache/crond/atd/进程，也许子进程并不会退出，这就意味着终止Aapche很可能引起CGI脚本仍在运行，PID变成init，跟踪这样的进程是很困难的。
systmed来拯救世界了：用systemctl kill命令你能轻松加愉快的给服务的所有进程发信号。例如：
# systemctl kill crond.service
这确保SIGTERM传递给crond服务的所有进程，而非仅仅是主进程。当然，你可根据需要发送不同的信号：
# systemctl kill -s SIGKILL crond.service
如你所愿，敌方服务所有进程团灭，不管它fork了多少次。
有时你想要的就是发个特定信号给服务主进程，也许你想通过SIGHUP触发reload。不使用PID文件，可以这样轻易做到：
# systemctl kill -s HUP --kill-who=main crond.service
systemd中杀死服务有什么新颖的东西呢？好吧，这是Linux中我们首次有正确的方法来做这件事。前面的解决方案总是依赖于守护进程的配合：当它们自己终止时，它们终止所有它们产生的进程。有时你会想用SIGTERM或者SIGKILL，因为守护进程有时不能和你合作愉快。
这种方法和systemctl stop有啥关系呢？kill直接发送信号给组中的所有进程，stop走官方配置渠道去关闭服务，比如调用在服务文件中的ExecStop=项。通常stop就足够了。kill是暴力版，只有在你不想用服务的官方渠道关闭命令，或者其他方法不起作用的时候，才启用它。
（-s 开关的参数加不加SIG前缀都行）
有点奇怪Linux这么长时间了都不能正确的杀死服务，systemd是首次让你能正确的做这件事的东东。
原文地址：http://0pointer.de/blog/projects/systemd-for-admins-4.htmlKilling ServicesKilling a system daemon is easy, right? Or is it?Sure, as long as your daemon persists only of a single process
systemd
（systemctl）编程
Linux
开机自启动
服务
脚本的方法（教程）
过去
Linux
采用的是init.d的
服务
启动管理方式，
新版的
Linux
采用
systemd
服务
启动管理方式，
请看教程讲解
请查阅我们的以获取有关最新系统版本中新功能的信息。
请参阅《以获取有关如何对
systemd
进行黑客攻击和测试您的修改的信息。
请参阅我们的，以获取有关提交GitHub问题和发布GitHub Pull Requests的更多信息。
在为
systemd
准备补丁时，请遵循我们的。
如果您需要支持，请联系我们的或加入我们的IRC频道。
与回迁的补丁稳定分支是可用的。
systemd
介绍
systemd
是目前
Linux
系统上主要的系统守护进程管理工具，由于init一方面对于进程的管理是串行化的，容易出现阻塞情况，另一方面init也仅仅是执行启动脚本，并不能对
服务
本身进行更多的管理。所以从CentOS 7开始也由
systemd
取代了init作为默认的系统进程管理工具。
systemd
所管理的所有系统资源都称作Unit，通过
systemd
命令集可以方便的对这些Unit进行管理。比如systemctl、hostnamectl、timedatectl、localctl等命令，这
通过ssh终端登录到一个red hat环境，通过nohup启动一个后台
服务
，在终端敲下exit命令后，后台
服务
被
systemd
杀死。
原因暂时未知，解决办法是通过注册
systemd
服务
来启动后台
服务
。
注册
systemd
服务
如下：
echo -e "[Unit]\nDescription=hello\n\n[Service]\nType=simple\nRestart=yes\nExecStart=/root/hello\n\n[Install]\nWantedBy=multi-user.target
CentOS 5使用SysV init；CentOS 6使用Upstart，CentOS 7使用
Systemd
管理守护进程。centos7采用
systemd
管理，
服务
独立的运行在内存中，
服务
响应速度快，但占用更多内存。独立
服务
的
服务
启动脚本都在目录 /usr/lib/
systemd
/system里。Systend的新特性：
- 系统引导时实现
服务
的并行启动；
- 按需激活进程；
- 系统实现快照；
- 基于依赖关系定义
服务
的控制逻辑；...............
ABRT是一个自动汇报错误的工具，主要是为用户提供简洁的，全面的错误信息
对于系统用户来说，它主要从系统日志中查询可以的字符串，比如oops、Machine-check、Xorg故障等，除了在系统日志中查询匹配外，它还检查kdump等记录故障的文件，从中提取系统错误信息，它提供了abrt-cli命令进行报告查看
通过提示命令查看
发现是
systemd
-l..
1号进程根据操作系统不同，运行着不同的进程，一般就是这几个
init、
systemd
、upstart
突发奇想，向1号进程发送kill -9 1会发生什么？可以成功将init进程
杀掉
吗？
根据manpage，一般情况下无法杀死init：
The only signals that can be sent to process ID 1, the init process, are those for which init has explicitly installed signal handlers.
kill -9 发送SIGKILL信号给进程，将其终止，但对于以下两种情况不适用
1.该进程是僵尸进程（STAT z），此时进程已经释放所有的资源，但是没有被父进程释放。僵尸进程要等到父进程结束，或者重启系统才可以被释放。
2.进程处于“核心态”，并且在等待不可获得的资源，处于“核心态 ”的资源默认忽略所有信号。只能重启系统。
kill 只能杀死处于用户状态的进程。
下面是一个自测试例子：
