标签 systemd 下的文章

去年随着Debian 以 systemd 作为 init 管理器的决议,以及随后的 init 系统投票,有三个人从 Debian 技术委员会退出:Colin Watson, Ian Jackson, 以及 Russ Allbery。现在,这些空缺席位现已由现有的技术委员会成员任命。

新任命的技术委员会成员是 Sam Hartman, Tollef Fog Heen 以及 Didier Raboud。这些新成员加上Bdale Garbee, Don Armstrong, Andreas Barth, Steve Langasek 以及 Keith Packard 组成了现在的Debian技术委员会。由Debian章程确定的 Debian 技术委员会(TC)负责对 Debian 项目中的技术争端做出最后的决定,他们在去年所有的关于 init 系统的讨论中变得十分重要。

新技术委员会成员的委任公告可以从 debian-devel-announce列表 中获悉。


via: http://www.phoronix.com/scan.php?page=news_item&px=Debian-TC-Three-Appointments

作者:Michael Larabel 译者:alim0x 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

我目前已从 chroot(译者注:chroot可以构建类似沙盒的环境,建议各位同学先了解chroot) 迁移到 systemd-nspawn,同时我写了一篇快速指南。简单的说,我强烈建议正在使用 systemd 的用户从 chroot 转为 systemd-nspawn,因为只要你的内核配置正确的话,它几乎没有什么缺点。

想必在各大发行版中的用户对 chroot 都不陌生,而且我猜想 Gentoo 用户要时不时的使用它。

chroot 面临的挑战

大多数交互环境下,仅运行chroot还不够。通常还要挂载 /proc, /sys,另外为了确保不会出现类似“丢失 ptys”之类的错误,我们还得 bind(译者注:bind 是 mount 的一个选项) 挂载 /dev。如果你使用 tmpfs,你可能想要以 tmpfs 类型挂载新的 tmp、 var/tmp。接下来你可能还想将其他的挂载点 bind 到 chroot 中。这些都不是特别难,但是一般情况下要写一个脚本来管理它。

现在我按照日常计划执行备份操作,当然有一些不必备份的数据如 tmp 目录,或任何 bind 挂载的内容。当我配置了一个新的 chroot 后就意味着我要更新我的备份配置了,但我经常忘记这点,因为大多数时间里 chroot 挂载点并没有运行。当这些挂载点仍然存在的情况下执行备份的话,那么备份中会多出很多不需要的内容。

当 bind 挂载点包含其他挂载点时(比如挂载时使用 -rbind 选项),这种情况下 systemd 的默认处理方式略有不同。在 bind 挂载中卸载一些东西时,systemd 会将处于 bind 另一边的目录也卸载掉。想像一下,如果我卸载了 chroot 中以 bind 挂载 /dev 的某个目录后,发现主机上的 /dev/pts 与 /dev/shm 也不见了,我肯定会很吃惊。不过好像有其他方法可以避免,但是这不是我们此次讨论的重点。

Systemd-nspawn 优点

Systemd-nspawn 用于启动一个容器,并且它的最简模式就可以像 chroot 那样运行。默认情况下,它自动配置容器所需的开销如 /dev, /tmp 等等。通过配合一些选项它也可配置其他的 bind 挂载点。当容器退出后,所有的挂载点都会被清除。

容器运行时,从外部看上去没什么变化。事实上,可以从同一个 chroot 产生5个不同的 systemd-nspawn 容器实例,并且除了文件系统(不包括 /dev, /tmp等,只有 /usr,/etc 的改变会传递)外它们之间没有任何联系。你的备份将会忽略 bind 挂载点、tmpfs 及任何挂载在容器中的内容。

它同时具有其它优秀容器的优点,比如 containment - 可以杀死容器内的所有活动但不影响外部,等等。它的安全性并不是无懈可击的-它的作用仅仅是防止意外的错误。

如果你使用的是兼容的 sysvinit(它包含了 systemd,openrc),你可以启动容器。这意味着,你可以在容器中使用 fstab 添加挂载点,运行守护进程等。只需要一个 chroot 的开销,几乎就可以获得虚拟化的所有好处(不需要构建内核等)。在一个看起来像 chroot 的容器中运行systemctl poweroff 看起来很奇怪,但这条命令能够起作用。

注意,如果不做额外配置的话那么容器就会共享主机的网络,所以主机上的容器不要运行 sshd。运行一个分离的网络 namespace 不是太难,为了新的实例可以使用DHCP,分离之后记得绑定接口。

操作步骤

让它工作起来是此次讨论中最简短的部分了。

首先系统内核要支持 namespaces 与 devpts:

CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y

像 chroot 那样启动 namespace 是非常简单的:

systemd-nspawn -D .

也可以像 chroot 那样退出。在内部可以运行 mount 并且可以看到默认它已将 /dev 与 /tmp 准备好了。 ”.“就是 chroot 的路径,也就是当前路径。在它内部运行的是 bash。

如果要添加一些 bind 挂载点也非常简便:

systemd-nspawn -D . --bind /usr/portage

现在,容器中的 /usr/portage 就与主机的对应目录绑定起来了,我们无需 sync /etc。如果想要绑定到指定的路径,只要在原路径后添加 ”:dest“,相当于 chroot 的 root(--bind foo 与 --bind foo:foo是一样的)。

如果容器具有 init 功能并且可以在内部运行,可以通过添加 -b 选项启动它:

systemd-nspawn -D . --bind /usr/portage -b

可以观察到 init 的运作。关闭容器会自动退出。

如果容器内运行了 systemd ,你可以使用 -h 选项将它的日志重定向到主机的systemd日志:

systemd-nspawn -D . --bind /usr/portage -j -b

使用 nspawn 注册容器以便它能够在 machinectl 中显示。如此可以方便的在主机上对它进行操作,如启动新的 getty, ssh 连接,关机等。

如果你正在使用 systemd 那么甩开 chroot 拥抱 nspawn 吧。


via: http://rich0gentoo.wordpress.com/2014/07/14/quick-systemd-nspawn-guide/

作者:rich0 译者:SPccman 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

在关于 systemd 的争议和内斗越来越多的这一年,systemd 的开发者们仍然保持了不断提交,在为这个项目增加代码上取得巨大成就。

作为昨天的“systemd 排名前列的开发者”帖子的补充,我今天早上用 GitStats 对 systemd 主干 Git 库进行了统计分析。以下数字说明了这一年 systemd 的增长:

在2014年,Systemd 得到了 4879 个提交,这要比2013年多28%,比2012年多91%。从最近的5000个提交来看,增加了418451行代码,并删除了203010行。

与其他主要成员如 Kay Sievers 和 Tom Gundersen 表现平平相比,Lennart Poettering 这一年一个人就提交了一大堆代码,他以1767个提交荣膺今年的 systemd 开发者的 No.1。其它的主要开发者还有: Tom Gundersen, Zbigniew JÄ™drzejewski-Szmek, Kay Sievers, David Herrmann, 和 Thomas Hindoe Paaboel Andersen.

在这一年的最后, systemd 的代码达到了 719,348 行。

从很久很久以前我们就在使用静态运行级别。而systemd提供了更为动态灵活的机制,来管控你的系统。

在开始介绍systemd命令前,让我们先简单的回顾一下历史。在Linux世界里,有一个很奇怪的现象,一方面Linux和自由软件(FOSS)在不断的向前推进,另一方面人们对这些变化却不断的抱怨。这就是为什么我要在此稍稍提及那些反对systemd所引起的争论的原因,因为我依然记得历史上有不少类似的争论:

  • 软件包(Pacakge)是邪恶的,因为真正的Linux用户会从源码构建他所想要的的一切,并严格的管理系统中安装的软件。
  • 解析依赖关系的包管理器是邪恶的,真正的Linux用户会手动解决这些该死的依赖关系。
  • apt-get总能把事情干好,所以只有Yum是邪恶的。
  • Red Hat简直就是Linux中的微软。
  • 好样的,Ubuntu!
  • 滚蛋吧,Ubuntu!

诸如此类...就像我之前常常说的一样,变化总是让人沮丧。这些该死的变化搅乱了我的工作流程,这可不是一件小事情,任何业务流程的中断,都会直接影响到生产力。但是,我们现在还处于计算机发展的婴儿期,在未来的很长的一段时间内将会持续有快速的变化和发展。想必大家应该都认识一些因循守旧的人,在他们的心里,商品一旦买回家以后就是恒久不变的,就像是买了一把扳手、一套家具或是一个粉红色的火烈鸟草坪装饰品。就是这些人,仍然在坚持使用Windows Vista,甚至还有人在使用运行Windows 95的老破烂机器和CRT显示器。他们不能理解为什么要去换一台新机器。老的还能用啊,不是么?

这让我回忆起了我在维护老电脑上的一项伟大的成就,那台破电脑真的早就该淘汰掉。从前我有个朋友有一台286的老机器,安装了一个极其老的MS-DOS版本。她使用这台电脑来处理一些简单的任务,比如说约会、日记、记账等,我还用BASIC给她写了一个简单的记账软件。她不用关注任何安全更新,是这样么?因为它压根都没有联网。所以我会时不时给她维修一下电脑,更换电阻、电容、电源或者是CMOS电池什么的。它竟然还一直能用。它那袖珍的琥珀CRT显示器变得越来越暗,在使用了20多年后,终于退出了历史舞台。现在我的这位朋友,换了一台运行Linux的老Thinkpad,来干同样的活。

前面的话题有点偏题了,下面抓紧时间开始介绍systemd。

运行级别 vs. 状态

SysVInit使用静态的运行级别来构建不同的启动状态,大部分发布版本中提供了以下5个运行级别:

  • 单用户模式(Single-user mode)
  • 多用户模式,不启动网络服务(Multi-user mode without network services started)
  • 多用户模式,启动网络服务(Multi-user mode with network services started)
  • 系统关机(System shutdown)
  • 系统重启(System reboot)

对于我来说,使用多个运行级别并没有太大的好处,但它们却一直在系统中存在着。 不同于运行级别,systemd可以创建不同的状态,状态提供了灵活的机制来设置启动时的配置项。这些状态是由多个unit文件组成的,状态又叫做启动目标(target)。启动目标有一个清晰的描述性命名,而不是像运行级别那样使用数字。unit文件可以控制服务、设备、套接字和挂载点。参考下/usr/lib/systemd/system/graphical.target,这是CentOS 7默认的启动目标:

[Unit]
Description=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target
After=multi-user.target
Conflicts=rescue.target
Wants=display-manager.service
AllowIsolate=yes
[Install]
Alias=default.target

现在再看看unit文件长什么样? 我来给大家找个例子。 unit文件存放在下面的两个目录下:

  • /etc/systemd/system/
  • /usr/lib/systemd/system/

我们可以修改第一个目录中的文件来进行自定义配置,而第二个目录中的文件是包安装时保存的备份。/etc/systemd/system/的优先级高于/usr/lib/systemd/system/。不错,用户优先级高于机器。下面是Apache Web server的unit文件:

[Unit]
Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target
[Service]
Type=notify
EnvironmentFile=/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd/ $OPTIONS -DFOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
ExecStop=/bin/kill -WINCH ${MAINPID}
KillSignal=SIGCONT
PrivateTmp=true
[Install]
WantedBy=multi.user.target

就算是对于新手而言,上面的文件也是非常简单易懂的。这可比SysVInit的init文件要简单多了,为了便于比较,下面截取了/etc/init.d/apache2的一个片段:

SCRIPTNAME="${0##*/}"
SCRIPTNAME="${SCRIPTNAME##[KS][0-9][0-9]}"
if [ -n "$APACHE_CONFDIR" ] ; then
    if [ "${APACHE_CONFDIR##/etc/apache2-}" != "${APACHE_CONFDIR}" ] ; then
            DIR_SUFFIX="${APACHE_CONFDIR##/etc/apache2-}"
    else
            DIR_SUFFIX=

整个文件一共有410行。

你可以检查unit文件的依赖关系,我常常被这些复杂的依赖关系给吓到:

$ systemctl list-dependencies httpd.service

cgroups

cgroups,或者叫控制组,在Linux内核里已经出现好几年了,但直到systemd的出现才被真正使用起来。The kernel documentation中是这样描述cgroups的:“控制组提供层次化的机制来管理任务组,使用它可以聚合和拆分任务组,并管理任务组后续产生的子任务。”换句话说,它提供了多种有效的方式来控制、限制和分配资源。systemd使用了cgroups,你可以便捷的查看它,使用下面的命令可以展示你系统中的整个cgroup树:

$ systemd-cgls

你可以使用ps命令来进行查看cgroup树:

$ ps xawf -eo pid,user,cgroup,args

常用命令集

下面的命令行展示了如何为守护进程重新装载配置文件,注意不是systemd服务文件。 使用这个命令能够激活新的配置项,且尽可能少的打断业务进程,下面以Apache为例:

# systemctl reload httpd.service

重新装载服务文件(service file)需要完全停止和重新启动服务。如果服务挂死了,用下面的命令行可以恢复它:

# systemctl restart httpd.service

你还可以用一个命令重启所有的守护进程。这个命令会重新装载所有守护进程的unit文件,然后重新生成依赖关系树:

# systemctl daemon-reload

在非特权模式下,你也可以进行重启、挂起、关机操作:

$ systemctl reboot
$ systemctl suspend
$ systemctl poweroff

按照惯例,最后给大家介绍一些systemd的学习材料。Here We Go Again, Another Linux Init: Intro to systemdUnderstanding and Using Systemd 是不错的入门材料,这两份文档里会链接到更多其他资源。


via: http://www.linux.com/learn/tutorials/794615-systemd-runlevels-and-service-management

作者:Carla Schroder 译者:coloka 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

Systemd 是目前为止在Linux平台上最有争议的项目之一。它到底有多大的争议?它的争议大到systemd的开发者之一Lennart Poettering 声称有人使用比特币雇佣职业杀手要干掉他。但是还是有比较理智的做法的,有一个抵制systemd网站在技术角度上提出了抵制systemd的原因。

如此强烈的抵制也反映了systemd的成功。它已经被或将要被Fedroa、OpenSUSE、Ubuntu、Debian、Arch Linux等众多发行版采用。随着时间推移,GNOME越来越依赖它,Debian回归GNOME的原因之一就是它采用了systemd。systemd无处不在!

那么如此激烈的争论到底是关于什么呢?让我们近距离观察这场战争。

Systemd是一个全新的init

Systemd的核心是取代老旧的SysV init。init用来初始化你的操作系统,当你启动系统时,init负责加载需要的驱动,激活你的网络链接,启动众多的系统服务,最后进入图形登陆界面。而SysV init 是一个老旧的系统,它基本上仅运行/etc/init.d目录下的一些脚本。

Systemd是一个现代技术,用以取代老旧以及粗糙的SysV init。它可以在接收到事件响应时启动相关服务;比如,当你接入了一个USB打印机,systemd可以在接收到设备接入响应时启动打印服务。当它接收到某个网络端口的连接请求时,它可以启动在此端口上监听的服务并且传递这个连接。

获取更多关于SysV init 与 systemd的信息,可以参考Jorgen Schäfer的 “Why systemd?

但是systemd远不止此

systemd的反对者之中也有部分人认为SysV太老了,应该被取代掉。但是批评systemd的人发现Systemd是一个巨大的项目,其中包括了很多其他的功能。它是一个软件套件,而不仅仅是一个init。

An illustration of systemd's structure.

维基共享资源 systemd 结构图解

Systemd包括用于管理用户登陆的守护进程logind,还包括journald,并且journald 颇有争议的使用了二进制形式保存系统日志而不是以文本形式。systemd也采用了udev的思想及代码,它对/dev/目录下的虚拟设备文件进行管理,并且处理设备接入或推出时所产生的事件。除了这些还有很多其他的,如:systemd还包括了cron风格的任务调度器与网络守护进程networkd等等。

抨击者认为systemd不是类UNIX风格

多数的抱怨源于人们认为systemd项目太大以至于超出了它的工作范围,并且它从Linux系统接管的部分太多了。不要感到惊奇,systemd的抵制活动是以下面的抱怨开始的:

"systemd文件是一大堆的复杂的高度耦合的二进制组成的,这违反了UNIX哲学:‘做一件事情,并把它做好’。它超出了一个init程序的职责范围,因为它还有电源管理,设备管理,挂载管理,cron(定时执行工具),磁盘加密,socket接口/inetd,syslog,网络配置,登陆/会话管理,文件预读,GPT分区发现,容器注册,hostname/locale/time管理,mDNS/DNS-SD等功能,它将Linux控制台以及其他的一些功能都包装在一个程序里面。

那么,systemd是好是坏?

到这里,我判断一下,到底谁是正确的。

systemd最初的想法是非常好的。Linux需要一个新的东西来替换老的 SysV init 和沉重的 SysV init 脚本,这个新的程序应该是灵活的,现代化的系统守护进程,它可以响应更多类型,并且智能化的管理众多的守护进程。然而,事实上systemd好像成为了一个仅依赖Linux核心的完全统一的系统层

但是,尽管Linux是一个社区开发项目,但它不是为PC世界的专栏作家或者是一群网络评论者提供的,这些人都不能决定它的进化与发展。只有那些亲手贡献代码以及全身心投入的人才有这个资格。巧的是,Linux发行版以及那些参与者好像大部分都倾向与systemd。

'我对于systemd本身并没有很强烈的个人看法。我与核心开发人员争论过它的bug与兼容性,并且我认为它的一些设计是愚蠢的(比如二进制的日志),但这只是细节,不是大问题。

如果 Linus Torvalds 对于systemd的设计没有什么反对意见,那么说明它可能还是不错的。如果你想平静的看下为什么Linux发行版要使用systemd的话,我推荐这篇文章,Debian's systemd discussion document

你是如何看systemd的,可以在评论回复!但是请文明讨论。

更新这篇文章以澄清之前的错误的消息,ubuntu 桌面版将在下一个版本中纳入systemd。之前我们错误的认为ubuntu已经使用了systemd


via: http://www.pcworld.com/article/2841873/meet-systemd-the-controversial-project-taking-over-a-linux-distro-near-you.html

作者:Chris Hoffman 译者:SPccman 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

编者按:Debian 8 Jessie的 init 系统默认使用 systemd,这一选择在社区引发了大量争议,导致了技术委员会的多名成员辞职。现在,“老兵 Unix 管理员”宣布要创建一个新的不使用 sytemd 的 Debian 分支。这群 Unix 哲学拥护者们请求外界捐赠支持他们的新使命。

以下内容来自 debianfork.org 的相关内容:


// 更新: 项目名称正式命名为:Devuan

我们是谁?!

我们是老兵 Unix 管理员(Veteran Unix Admins),我们非常关注 Debian GNU/Linux 在 systemd 上的分歧,并且决定分支(fork)Debian 项目。

为什么我们要这样做?

我们中的一些人是上游开发者,一些人是专业的系统管理员:我们每天都要和 Debian 打各种交道。

我们不想被强迫使用 systemd 来替代传统的 UNIX sysvinit 初始化系统,因为 systemd 背离了 UNIX 哲学。

我们考虑采用贴近 sysvinit 的架构,而不是那种破坏了“做一件事,把它做好”的原则、带着数十个紧密耦合的二进制文件和不透明的日志的东西。

有比创建分支更好的解决方案么?

不幸的是,目前没有!

在下一代的 Debian v.8 "Jessie" 发行版中,默认的初始化系统将是 systemd,它将挟裹着一堆紧密纠缠的东西来到。

我们需要分离这些依赖的牵扯,从所有受到影响的软件包中清除这些,并提供相应的替代品。我们所要创建的分支的稳定性是目前阶段所要考虑的首要重点。

你觉得为什么会走到了这一步?

现在的 Debian 项目的领导者受到了 GNOME 开发者太多的影响,而且在项目中考虑了太多的桌面需求的因素,而 Debian 用户却大多数是精通技术的系统管理员。

而且,今天 Debian 正逐渐背离自己最初愿景,也是开源软件的基石:用户至上。这到底是怎么了?所谓的“do-ocracy”开发者和包维护者正在给用户强加他们的选择。

你可以说一下你对 systemd 的意见吗?

套用一下 Eric S. Raymond 在这个问题上的看法,我们认为 systemd 很容易就会发生嬗变,进而臃肿不堪、最后变成了那种讨厌的纠结在一起的毛球。

我们希望能够用可以阅读的 shell 脚本来控制系统的启动,因为可读性能够给我们这些有能力的人更多的控制和洞悉。我们认为,在一个守护进程中集中控制服务、socket、设备、挂载等等,是对传统的 UNIX 哲学的一记响亮耳光。

某些支持 systemd 的人对此的快速回应可以在 forkfedora.org (已经关闭,需要翻墙才能看历史归档)上看到。这个页面突出了两者之间的根本不同:systemd 也许对于配置 init 来说很简单,但是它增加了 init 过程中的不透明度。在 systemd 中很明确是这样的:可以通过更少的变量来调整,而通过远超 sysvinit 大小的程序将大部分细节隐藏在一个巨大的二进制程序里面。

  ls -lH /sbin/init
  sysvinit: -rwxr-xr-x 1 root root 36992 Jul 14  2013 /sbin/init
  systemd: -rwxr-xr-x 1 root root 1317632 Sep  1 14:41 /sbin/init
# 你也许认为我不够强大,但是你也太胖了!

可以说 systemd 的安全模式更多的依赖于开发者和包维护者,而不怎么指望系统管理员。作为 Debian 用户,我们只是希望不要被强迫必须如此,看看 CTTE 关于这个问题的投票就会知道,我们相信这样下去会越来越多的听到用户要求:放开那个 Init !不要和 systemd 和它的那堆零碎纠缠在一起。

你们能坚持多久?

这不是比谁的胡子更长,放心,毛茸茸的不总是绵羊!

概括一下计划?

“放开那个 Init”( Init Freedom),这是我们的承诺,我们会建立一个 Debian 项目的分支,创建一个新的基础发行版。

这需要一些时间,我们会一步步来。

首先我们会配合 Debian 8 "Jessie" 的发布,给当前的 Debian 用户平滑升级提供一个完整的解决方案。

如果你也需要这个,请帮助我们: 捐赠 或者参与进来。

我们需要谈谈。

当然,您可以写电子邮件给 [email protected]

我们也有一些人聚集在 IRC , Freenode 频道号是 #debianfork ,欢迎加入。

可以订阅邮件列表。喜欢的话来发布意见吧,不管是什么。

只有你们这些家伙吗?

不是,有很多用户都对 systemd 有意见。

有一篇文章是对这个问题的很好的介绍: Systemd: Linux 世界末日的预兆

有个 boycott systemd 网站也有一些相关的资料。那里有个叫做 uselessd 的 “systemd 分支”,有些不错的地方和许多笑点(lulz)。

还有人提出了一个 当世界 systemd 了之后的撤退战略。

在维基百科的 systemd reception 章节也有一些对其提出的批评意见。

谢谢你做的这些,我怎么帮助你们?

老兵 Unix 管理员(Veteran Unix Admins)的一个小型的核心小组正在积极建设分支的相关框架和一些用于开发的基础设施。

这时的捐赠有助于我们确定可以在基础架构上投入多少以及人们的对我们的预期。

如果你会捐赠,那么来吧

如我们现在做的,我们会在此一直更新我们的项目进展。

对于你做的这些,人们是怎么看的?

下面是我们收到的一些邮件(略,请参照原链接),我们会匿名发表这些信息,除非你申明不用。

我们会保密你的邮件地址,并会通知你我们的下一步进展。