[arch-general] systemd adds entries to /etc/mtab
I just switched to systemd, and was poking around a bit when I noticed many new entries in /etc/mtab: ... securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0 tmpfs /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec,mode=755 0 0 cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0 cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0 cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpuacct,cpu 0 0 cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0 cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0 cgroup /sys/fs/cgroup/net_cls cgroup rw,nosuid,nodev,noexec,relatime,net_cls 0 0 cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0 systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=21,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0 debugfs /sys/kernel/debug debugfs rw,relatime 0 0 mqueue /dev/mqueue mqueue rw,relatime 0 0 tmpfs /tmp tmpfs rw 0 0 fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0 In particular, I notice that /dev/hugepages, /dev/mqueue, and /sys/kernel/debug seem to correspond to unit files dev-hugepages.mount, dev-mqueue.mount, and sys-kernel-debug.mount, respectively. As I'm trying to pare down the output of systemctl list-units, I'd like to know if these things can safely be removed. (Nothing has gone wrong, but I'm just curious, and can't seem to find much online about the relevance of these things to systemd.) Many thanks, J.M.
On Sat, Oct 20, 2012 at 3:01 AM, Janna M. <janna.martl109@gmail.com> wrote:
I just switched to systemd, and was poking around a bit when I noticed many new entries in /etc/mtab:
... securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,**relatime 0 0 tmpfs /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec,mode=**755 0 0 cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,**relatime,release_agent=/usr/** lib/systemd/systemd-cgroups-**agent,name=systemd 0 0 cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,**relatime,cpuset 0 0 cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,**relatime,cpuacct,cpu 0 0 cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,**relatime,devices 0 0 cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,**relatime,freezer 0 0 cgroup /sys/fs/cgroup/net_cls cgroup rw,nosuid,nodev,noexec,**relatime,net_cls 0 0 cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,**relatime,blkio 0 0 systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=21,pgrp=1,** timeout=300,minproto=5,**maxproto=5,direct 0 0 hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0 debugfs /sys/kernel/debug debugfs rw,relatime 0 0 mqueue /dev/mqueue mqueue rw,relatime 0 0 tmpfs /tmp tmpfs rw 0 0 fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
In particular, I notice that /dev/hugepages, /dev/mqueue, and /sys/kernel/debug seem to correspond to unit files dev-hugepages.mount, dev-mqueue.mount, and sys-kernel-debug.mount, respectively. As I'm trying to pare down the output of systemctl list-units, I'd like to know if these things can safely be removed.
Note that recent systemd versions include a link to the documentation of some units. For example: $ systemctl status dev-mqueue.mount | grep Docs Docs: man:mq_overview(7) So doing: $ man 7 mq_overview will give you an overview of what it is used for. Generally speaking, these are sometimes called "API filesystems" because they povide kernel services to applications instead of file storage. They can be removed only if none of your running applications use them, but that could be difficult to assert. And since they use almost no resources for just being mounted, there is little reason for not mounting them at system startup. That's why systemd does it automatically by default. However, you can try disabling them and see what happens. In particular disabling the debugfs thing should do no harm. PS: There is a very thorough and interesting series about the hugepages at LWN: [1] [2] [3] [4] [5]. [1]: http://lwn.net/Articles/374424/ [2]: http://lwn.net/Articles/375096/ [3]: http://lwn.net/Articles/376606/ [4]: http://lwn.net/Articles/378641/ [5]: http://lwn.net/Articles/379748/ -- Rodrigo
On Sat, Oct 20, 2012 at 10:21:53AM +0200, Rodrigo Rivas wrote:
On Sat, Oct 20, 2012 at 3:01 AM, Janna M. <janna.martl109@gmail.com> wrote:
I just switched to systemd, and was poking around a bit when I noticed many new entries in /etc/mtab:
...
Note that recent systemd versions include a link to the documentation of some units. For example:
$ systemctl status dev-mqueue.mount | grep Docs Docs: man:mq_overview(7)
So doing:
$ man 7 mq_overview
will give you an overview of what it is used for.
Generally speaking, these are sometimes called "API filesystems" because they povide kernel services to applications instead of file storage. They can be removed only if none of your running applications use them, but that could be difficult to assert. And since they use almost no resources for just being mounted, there is little reason for not mounting them at system startup. That's why systemd does it automatically by default.
However, you can try disabling them and see what happens. In particular disabling the debugfs thing should do no harm.
PS: There is a very thorough and interesting series about the hugepages at LWN: [1] [2] [3] [4] [5].
[1]: http://lwn.net/Articles/374424/ [2]: http://lwn.net/Articles/375096/ [3]: http://lwn.net/Articles/376606/ [4]: http://lwn.net/Articles/378641/ [5]: http://lwn.net/Articles/379748/
-- Rodrigo
Very interesting; thanks!
Am 20.10.2012 03:01, schrieb Janna M.:
I just switched to systemd, and was poking around a bit when I noticed many new entries in /etc/mtab:
mtab is not a regular file anymore, but a symlink to /proc/self/mounts. Systemd mounts many new virtual file systems that we didn't use with initscripts. Use 'findmnt' for a more readable output.
participants (3)
-
Janna M.
-
Rodrigo Rivas
-
Thomas Bächler