在最近升级到 Fedora 15 后，我发现许多工具失败并出现以下错误：
tail: inotify resources exhausted
tail: inotify cannot be used, reverting to polling
这不仅仅是tail报告 inotify 的问题。有没有办法询问内核以找出正在消耗 inotify 资源的进程？当前与 inotify 相关的sysctl设置如下所示：
fs.inotify.max_user_instances = 128
fs.inotify.max_user_watches = 8192
fs.inotify.max_queued_events = 16384
假设您有一个 shell 脚本，它通过EXIT陷阱运行某种清理代码，如下所示：
#!/bin/bash
mytrap () {
echo "It's a trap!" >&2
}
trap mytrap exit
echo I am at the end of the script.
正如预期的那样，这将It's a trap!在脚本退出时打印出来：
$ sh myscript
I am at the end of the script.
It's a trap!
您修改脚本以添加一个函数，该函数生成一些最终通过管道传输到另一个命令的输出，如下所示：
#!/bin/bash
mytrap () {
echo "It's a trap!" >&2
}
myfunc () {
echo "I've got a bad feeling about this..."
}
trap mytrap exit
myfunc | cat > /dev/null
echo I am …使用 OS X 和 iOS 中的 CoreMIDI 子系统提供的网络 midi（显然是 RTP-MIDI）的本机支持，我可以轻松地将 iPad 连接到 Macbook 上的 MIDI 应用程序.
是否有兼容的 Linux 实现？我发现了一些引人入胜的参考资料，表明可能有这样的参考资料，但我找不到任何具体信息。
我正在尝试在 Fedora 19 下使用 selinux（selinux-policy-targeted）在强制模式下运行 OpenVPN，并且我遇到了 AVC，我不完全确定如何处理。
以 root 身份从命令行启动 OpenVPN 工作正常，但通过 systemd ( systemctl start openvpn@vpcbridge，如果
/etc/openvpn/vpcbridge.conf存在)启动它会导致：
ERROR: Cannot ioctl TUNSETIFF tap0: Permission denied (errno=13)
并在/var/log/audit：
type=AVC msg=audit(1376412420.435:60): avc: denied { relabelfrom } for
pid=720 comm="openvpn" scontext=system_u:system_r:openvpn_t:s0
tcontext=system_u:system_r:ifconfig_t:s0 tclass=tun_socket
作为参考，这里是 OpenVPN 配置：
port 1194
user openvpn
dev tap0
proto udp
secret vpcbridge.key
keepalive 10 120
persist-tun
persist-key
如果我运行audit2allow，我会得到一个如下所示的模块文件：
module openvpn 1.0;
require {
type openvpn_t;
type ifconfig_t;
class tun_socket relabelfrom;
}
#============= openvpn_t …我对 XTerm 和 Unicode 没有普遍的问题。在大多数情况下，事情正在发挥作用。这很好用：
$ echo "¿dónde está la llama?"
¿dónde está la llama?
就像这样：
$ echo -e "\xE2\x98\xA0"
?
但是这个失败：
$ echo -e "\xE2\xA4\xB7"
而不是预期的输出（？，又名箭头向下然后向右弯曲）我得到了可怕的盒子。我目前正在使用：
xterm*faceName: Hack Regular:size=12:antialias=true
这是我使用的相同字体gnome-terminal，它可以正确显示相同的字符。我还尝试过使用其他各种等宽字体（Droid Sans Mono、DejaVu Sans Mono、Liberation Mono）进行相同的操作，它们在 XTerm 中都具有相同的行为（但在其他地方工作正常）。实际上，查看\u2620显示正确的 和显示不正确的之间的字符\u2937，有许多字符在 XTerm 中似乎无法正确显示：
$ python
>>> for x in range(0x2620, 0x2938):
... print(unichr(x))
我想了解这里发生了什么。为什么 XTerm 无法显示其中一些字符，而其他字符却没有？
我遇到了一个关于 Linux 上挂载命名空间的奇怪问题。我有两个系统，两个 X86_64 都在 Fedora 16 下运行内核 3.2.3-2。我试图tmpfs在使用以下unshare命令创建的子命名空间中挂载文件系统：
unshare -m /bin/bash
从手册页：
mount namespace
mounting and unmounting filesystems will not affect rest of the
system (CLONE_NEWNS flag),
在一个系统上，这按预期工作。也就是说，如果我从这个开始：
# ls /mnt
file1 file2 file3
然后在子命名空间中挂载tmpfs文件系统/mnt：
# PS1="child# ' unshare -m /bin/bash
child# mount -t tmpfs tmpfs /mnt
的内容/mnt在子命名空间中被屏蔽：
child# ls /mnt
child#
但继续在父级中可见：
# ls /mnt
file1 file2 file3
在第二个系统上，完全相同的命令序列将导致在父命名空间和子命名空间中可见的挂载。换句话说，似乎该unshare命令实际上并没有产生单独的挂载命名空间。
我不知道这两个系统之间有任何实质性差异。一个是运行桌面环境，另一个不是。SELinux 在两个系统上都被禁用。
我正在寻找有关可能导致这种行为差异的原因的任何建议。
我有一个在 Fedora 31 主机上运行的 CentOS 8 来宾。来宾连接到桥接网络virbr0，并且具有地址192.168.122.217。我可以通过该地址的 ssh 登录来宾。
如果我在监听端口 80 的来宾上启动服务，从主机到来宾的所有连接都会失败，如下所示：
$ curl 192.168.122.217
curl: (7) Failed to connect to 192.168.122.217 port 80: No route to host
该服务必须0.0.0.0：
guest# ss -tln
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 5 0.0.0.0:80 0.0.0.0:*
LISTEN 0 128 [::]:22 [::]:*
使用tcpdump（virbr0在主机上或在eth0来宾上），我看到来宾似乎在回复 ICMP“禁止管理员”消息。
19:09:25.698175 IP 192.168.122.1.33472 > 192.168.122.217.http: Flags [S], seq 959177236, win 64240, options …我用（CentOS/RHEL）虚拟机做了很多本地开发工作。与其使用默认的 root 密码配置所有内容——如果暴露在网络中，可能会出现问题——我想将它们配置为仅允许在串行控制台上进行无密码 root 登录。
我的第一次尝试是使用以下选项简单地用命令行替换默认ExecStart命令 ：serial-getty@.service--autologin
ExecStart=-/sbin/agetty -o '-p -- \\u' --keep-baud 115200,38400,9600 --noclear --autologin root ttyS0 $TERM
虽然这会跳过login:提示，但它仍会提示输入 root 密码。这似乎是loginLinux 下程序的一个限制。
我还尝试用 shell 替换默认登录程序，如下所示：
ExecStart=-/sbin/agetty -o '-p -- \\u' --keep-baud 115200,38400,9600 --noclear -n -l /bin/bash ttyS0 $TERM
但这与 selinux 发生冲突：虽然我得到了一个bashshell，但它无法访问任何东西：
bash: /root/.bashrc: Permission denied
# ls /etc/systemd
ls: cannot open directory '/etc/systemd': Permission denied
在网络的其他地方，人们建议只从 中删除密码哈希/etc/{password,shadow}，但这当然会导致一系列不同的问题：现在任何用户都可以su -没有密码。
关于如何使其正常工作的任何想法？