分类： Linux

UPS (Uninterruptible Power Supply)，是一种含有储能装置的不间断电源。主要用于给部分对电源稳定性要求较高的设备，提供不间断的电源。

一般的 UPS 都支持通过 USB 连接到电脑或者 NAS 等设备上，Linux/Mac/Windows 均支持使用 UPS。

因为电路不稳定，存在偶尔断电的情况，因此希望通过 UPS 保护树莓派、路由器、光猫、硬盘录像机等设备；将 UPS 通过 USB 接口连接到树莓派，由树莓派控制其他设备在断电时关机。

当前主要有两个方案，一个是 NUT(Network UPS Tools)  另一个是使用 apcupsd (Apcupsd UPS control software)，两者二选一即可。

如果是群晖，可能只有使用 NUT(Network UPS Tools)  ，如果使用 U-NAS 可能只能使用  apcupsd (Apcupsd UPS control software)。

从配置简便性上，推荐  apcupsd (Apcupsd UPS control software)。

apcupsd 配置

虽然施奈德官方提供的 PowerChute 软件只支持 Windows 系统，但 Linux 下亦有 apcupsd 可以使用。该软件以守护进程的方式运行，通过串行数据通信的方式（串口或 USB ）实时获取 UPS 电源信息，包括当前外部输入电压、负载功率、电池电量等。当电池电量低于指定值时，会自动运行脚本程序 /etc/apcupsd/apccontrol ，以实现电脑系统的自动关闭或任何用户指定的操作。

把 UPS 电源与电脑连好后，根据 apcupsd 的说明文档，我们首先使用 lsusb 命令检查 Linux 系统是否能检测到已连接的 UPS 电源。

确认能够找到设备后。

安装：

编辑 apcupsd 的配置文件 /etc/apcupsd/apcupsd.conf，将其中 UPSCABLE 与 UPSTYPE 两项均设为 usb 。

因为台式机与 UPS 电源之间是通过 USB 通讯的，所以需要注释掉配置文件中的串口设置部分：

将 NISIP 值设为 0.0.0.0 或你想绑定的指定主机 IP

其余保持默认即可。

至此，可以启动 apcupsd 系统服务了。

该服务启动后，除了正常的 UPS 电源实时监测外，还会在本机的端口上开启一个服务器。我们可以在命令行终端使用apcaccess命令来获得电源的运行状态。其中的主要参数为：

• LINEV：线电压

• LOADPCT：负载占比

• TIMELEFT：电池剩余维持时间

• LOTRANS：最低容许输入电压

• HITRANS：最高容许输入电压

• BATTV：电池输出电压

• NOMPOWER：额定功率

客户端配置：

安装：

打开 apcupsd 配置文件 /etc/apcupsd/apcupsd.conf

• 将 UPSCABLE 值设为 ether
• 将 UPSTYPE 值设为 net
• 将 DEVICE 值设为你的 apcupsd 服务端地址和端口（也就是和 UPS 以 USB 相连接的主机）

与 NIS 相关的设置保持默认（也就是保持 NETSERVER 为 on）

启动 apcupsd 服务，输入 apcaccess 命令，你应该能看到 apcupsd 输出电源信息。

NUT 配置

安装 NUT

NUT (Network UPS Tools) 是一种开源软件工具，其主要功能特点是实时监控与管理不间断电源（UPS）设备，支持多种通信协议，自动执行操作以应对电力故障，适用于多平台，并允许集中管理多个UPS设备，以确保与这些设备连接的计算机和设备在电力问题发生时能够继续正常运行或安全关闭。

NUT中的主要软件组件和功能：

• Driver（驱动程序）：NUT包括各种不同制造商的UPS设备的驱动程序，使NUT能够与多种型号的UPS设备通信。这些驱动程序负责与UPS设备建立连接，并获取有关电源状态、电池状态和其他参数的信息。

• upsd（UPS守护进程）：upsd是NUT的核心守护进程，负责与UPS设备通信，并将UPS状态信息提供给其他NUT组件和客户端。它可以通过网络协议（如SNMP、HTTP、XML-RPC等）向其他计算机提供UPS状态信息。

• upsmon（UPS监控守护进程）：upsmon监控守护进程用于监视UPS状态，并在检测到电力问题时执行操作。它可以配置为执行自定义脚本、关闭计算机或发送警报通知，以确保系统的连续性和数据完整性。

• upslog（UPS事件记录器）：upslog用于记录UPS事件和状态信息，以便后续分析和故障排除。它可以生成日志文件，其中包含UPS的运行历史和电力事件。

• nutclient（NUT客户端工具）：NUT提供了一些用于监控和管理UPS的命令行工具，例如upsc用于查询UPS状态，upscmd用于发送命令到UPS，以及upsrw用于修改UPS配置。

• 安装

通过 USB 连接 UPS

在将 UPS 通过 USB 连接到树莓派后，可以通过查看 USB 设备进行检查

• 检查 USB 连接

其中的 Device 003 就是 UPS，说明 USB 连接正常

• 通过 nut-scanner 检查 UPS 设备

正确识别到连接的 UPS 设备，驱动为 usbhid-ups，产品为 SANTAK TG-BOX

或者如下：

配置 UPS

###配置 UPS 驱动

驱动程序负责与UPS设备建立连接，并获取有关电源状态、电池状态和其他参数的信息

• 将 UPS 设备添加到 NUT

使用 nut-scanner 将连接的 UPS 信息追加到 /etc/nut/ups.conf 配置中，其中的 nutdev1 是设备的名称，可以自定义

• 启动 NUT

使用 upsdrvctl 命令启动 NUT

配置 UPS 守护进程

upsd 负责与UPS设备通信，并将UPS状态信息提供给其他NUT组件和客户端

• 启动 upsd

查看 UPS 状态

使用 upsc 命令查看 UPS 设备的状态；其中的 nutdev1 是 /etc/nut/ups.conf 中配置的名称

该命令会返回 UPS 设备的所有信息

也可以指定名称查看 UPS 状态

配置关机策略

配置 upsd 用户

upsd 用户对应的配置文件是 /etc/nut/upsd.users，配置用户用于读取 UPS的信息；在以下配置中，用户名是 upsmon，密码是 123456，运行模式是 master，即该设备为主节点（如果有同时使用其他 UPS则可以是 slave）

• 重启 upsd

配置关机策略

关机策略使用的是 upsmon，upsmon 监控守护进程用于监视UPS状态，并在检测到电力问题时执行操作，它可以配置为执行自定义脚本、关闭计算机或发送警报通知

• 配置关机策略

修改 /etc/nut/upsmon.conf，添加如下配置，使用的是刚才创建的用户信息，这样，当设备监听到 UPS 发出的 LOWBATT 命令后，就会执行关闭系统

这个命令告诉NUT要监控名为 “ups” 的UPS设备，该设备位于本地主机上。监控用户 “monuser”，可以使用密码 “123456” 连接到NUT，并具有 “master” 角色的权限。这允许用户通过NUT连接来监视和管理UPS设备

• 启动 upsmon

执行自定义动作

NUT 通过 upssched 支持监听 UPS 事件并执行指定脚本，因此可以用于执行一些自定义的动作，如发送通知等

配置 upsmon

修改 /etc/nut/upsmon.conf 文件，添加如下配置

• 指定运行命令

该配置用于在发生事件时运行 /sbin/upssched 服务

• 配置触发条件

这里监听了 ONLINE, ONBATT, 和 LOWBATT三个事件，分别是电源供电、电池供电和低电量事件；SYSLOG声明记录事件日志到系统中，WALL声明通知所有在线用户，EXEC 声明需要执行命令

配置 upssched

配置好 upsmon 后，还需要配置 upssched 执行相关的命令，需要将以下内容添加到 /etc/nut/upssched.conf 中

• 配置 upsmon

CMDSCRIPT 指定了监听到事件后需要执行的脚本 PIPEFN和LOCKFN指定了监听事件的管道并加锁，避免被修改 AT 和 EXECUTE 指定了监听的事件并执行相关的脚本；当监听到 ONBATT, ONLINE 和 LOWBATT 时执行 CMDSCRIPT指定的脚本，并将 battery_on, power_online 和 low_battery作为参数 AT 和 START-TIMER 启动了一个计时器，在 60s 后执行 AT 和 CANCEL-TIMER 指定如果在启动计时器60s 内发生了 ONLINE事件，则取消计时器

• 配置 upssched-script.sh

这段脚本用于接收事件，并执行动作；这里通过 Bark 发送了通知

记录 UPS 日志

ups 支持通过 upslog 记录 UPS 日志

这段命令中，通过 -l指定了输出文件为 /var/log/ups.log，-i 1 表示1s输出一次，-s ups@localhost指定了 UPS 位置，-f 指定了日志输出格式

输出日志参考：

配置 UPS 监控

NUT 支持通过 HTTP 接口对外提供 UPS 的信息，因此可以用于监控 UPS; https://github.com/helloworlde/nut_exporter 提供了 Prometheus Exporter，可以使用 Prometheus 和 Grafana 对 UPS 进行监控

修改 NUT 运行模式

配置文件是 /etc/nut/nut.conf；将模式修改为 netserver的目的是允许通过局域网访问 UPS 的设备信息，用于其他设备监控、监听 UPS 的状态；如果不需要监听则不需要配置

配置 upsd

修改 upsd 对应的配置文件 /etc/nut/upsd.conf，添加监听的地址和端口；添加局域网 IP 是用于局域网内其他设备进行监控，否则可能会拒绝连接

• 重启 upsd

配置 NUT Exporter

• 配置 docker-compose.yaml

• 配置 .env

Server 的地址即为树莓派局域网的IP地址，用户名和密码是 upsd 的用户和密码；NUT_EXPORTER_VARIABLES是需要抓取的监控指标类型，不同的设备可能指标不一样；可以通过 upsc ups@localhost 获取所有的指标名称进行替换

• 配置 Prometheus

• 配置 Grafana 面板

导入 https://github.com/helloworlde/nut_exporter/blob/master/dashboard/dashboard.json 即可

参考链接

---

• Linux 环境下配置不间断电源 UPS
• Linux 上的 UPS 工具 NUT
• 使用NUT和apcupsd将群晖NAS接入UPS不间断电源
• 使用 apcupsd 实现 UPS 断电自动关机
• 在Linux下使用UPS电源与监控程序配置

据外媒 Phoronix 报道，GNOME 桌面环境在最近合并的 PR 中获得了远程桌面协议（RDP）支持，预计相关特性将集成至 2024 年 3 月发布的 GNOME 46 版本中，届时 Linux 发行版用户能够更方便地使用 RDP 软件远程访问桌面环境。

这项 RDP 功能同时支持 X.Org 与 Wayland 显示服务器协议，可作为系统服务运行，也可在无 header 用户会话中运行，从而为 GNOME 桌面环境实现 GUI 远程桌面能力。

继续阅读GNOME 46 桌面环境加入 RDP 协议支持，今年 3 月起 Linux 发行版用户远程登录更轻松

如果你是一个 Linux 用户，那你一定至少听说过 Glibc 的鼎鼎大名，或者甚至在日常使用中碰到不少关于它的问题，例如 Glibc 版本不匹配等问题。而本文的主角—— Musl libc 与之相比就要默默无闻的多，毕竟绝大多数的 Linux 发行版使用的 libc 库都是 Glibc，只有 Alpine Linux 等极少数 Linux 发行版才会使用 Musl libc，并且还会遇到诸如闭源 JDK 无法正常使用等问题的困扰，那么，为什么我们会需要另一个 libc 函数库呢？

Glibc 并不完美

Glibc 作为目前使用最广泛的 libc 函数库，虽然拥有最广泛的发行版支持和用户群体，并且在兼容性和性能方面也存在一些优势，但它并不完美，有三个问题严重困扰着它。

代码库陈旧

Glibc 拥有悠久的历史——对于软件而言这可能并不一定是一句赞誉，尤其是当你需要处理上世纪九十年代就存在的代码库时。三十多年来，程序员们编写 C 程序的方式并不是一成不变的，某些在那个年代被认为是好习惯或者是必须的编程方式在今天看来可能完全不合时宜，诸如叠床架屋的宏等等。这些问题严重拖累了 Glibc 的源码可读性，例如下面这一段源代码，摘自 Glibc 的 fopen 函数。

作为对比，下面是 Musl 库中同样对 fopen 函数的实现

两者的可读性差距不言自明，笔者在这里并非是要批判 Glibc 的代码风格，但对于初次上手阅读源码的人来说，显然是 Musl 的风格更加友好，更便于理解。

体积过大

由于 Glibc 相较体积更加关注性能，因此其链接生成的二进制文件相较于 Musl uClibc 等专注于嵌入式等场合的库来说要大很多，而这些场合往往非常关注几百 K 大小的区别，因为 SRAM 的大小往往关乎整体开发板的成本。

下面这张表展示了不同 libc 库编译的文件大小。

尺寸对比	musl	uClibc	dietlibc	glibc
.a	426k	500k	120k	2.0M
.so	527k	560k	185k	7.9M
静态最小	1.8k	5k	0.2k	662k
静态输出	13k	70k	6k	662k

可以看出 Glibc 在程序大小上明显大于其他 libc 库，此外，这里的静态也是有水分的，这就引出了 Glibc 的下一个问题，也是最重要的问题之一：静态链接。

对静态链接支持不佳

理论上来说，Glibc 是支持静态链接的。但，这也仅仅是从理论上来说，由于一些历史遗留问题（当然，也包括对功能实现的考虑）Glibc 的静态链接并不是真正的静态链接：如果你的程序中使用了某些不支持静态链接的特性（这一点在大型软件中非常常见），那么即便你在链接时选择静态链接，生成出来的程序实际上仍然是依赖于 Glibc 动态库的，一旦你尝试删除掉它，你立马就会发现这些“静态”链接的程序统统罢工不干了。

谁在用 Musl？

在发行版中，主要是 Alpine Linux，作为最特立独行的 Linux 发行版之一，它选用了 Musl + Busybox 的组合，而非通常的 Glibc + Coreutils，这使得它的最小安装可以控制在惊人的 5 MB 之内！相比之下，普通的 CentOS 最小安装则需要 200 MB 左右，这一点使得它在嵌入式等对内存占用极为敏感的场合占据了相当的优势。

此外，Musl 从设计之初就很关注静态链接的可用性，因此它完全可以被静态链接进其他程序中，不存在 Glibc 对动态库的依赖问题，这一点也有助于缓解不同版本 libc 之间的兼容性问题——只要我把万物都静态链接进去，就不存在版本问题了。当然，这种做法也会带来体积膨胀等问题，所以并不是一个太好的解决方案。

Musl 的问题与未来

虽然拥有诸多优点，但 Musl 在性能方面逊于 Glibc 也是不争的事实，毕竟简化实现的代价就包括牺牲性能，不过这一点并非不可拯救，通过使用开源的 malloc 实现（诸如微软的实现）替换这些对性能影响较大的热点函数，就可以在很大程度上解决性能方面的问题。

同时，试图取代或至少部分取代 Glibc 的库也并不止 Musl 一个， 例如用于 AOSP 项目上的 bionic，以及广泛应用于各种嵌入式开发中的 uClibc 等。与它们相比，Musl 背后既没有 Google 这样的大公司撑腰，在压缩体积方面做的也不够极致，相较之下就没有那么受到开发者们的青睐，在新功能和新特性跟进上也不是非常积极。

出于这些原因，也许 Musl 在今后的很长一段时间内会继续保持这种“小而美”的特点，但这对于我们来说并非就是一件坏事，能够看到与 GNU Glibc 风格截然不同的另一种实现，对于 Linux 社区的多样性，以及对于我们这些学习者来说，何尝不是一件美事？

参考链接

---

• musl libc home page
• Alpine Linux
• Comparison of C/POSIX standard library implementations for Linux
• Building LLVM

Comparing performances

I decided to compare the performances of the OpenSource Linux Userspace Emulator that allows you to run x86/x86_64 apps on ARM linux. There are QEMU-user, FEX-emu and Box86/Box64.

How to bench Linux userspace emulator

Test will consist of the bench I already used a couple of time, and that can be run as native or emulated:

• 7-zip integrated benchmark, that contains mostly integer code (no x87 or SSE), and can be used as a baseline to see the pure x86 code translation efficiency. The version 16 present in Ubuntu was used for those tests.
• dav1d, an opensource video transcoding tool, that includes hand-optimized SSE assembly code (SSE3 or more).
• glmark2 that is GL limited and should run at mostly native speed (as long as GL is hardware accelerated). I couldn’t install the armhf version of glmark2 on Ubuntu, so only the native 64bits version was benchmarked.
• openarena, that contains x87 code, and a JIT, and, in that config, is very much GPU limited, and so should be running very close to the native speed (again, as long as GL is still hardware accelerated).

The 7z, dav1d and glmark2 bench are described here, and the openarena one there.

I’ll also do some quick bench not available natively. The fps will simply be measured with HUD_GALLIUM=fps on a stable and reproducible moment in the game:

• WorldOfGoo: The game has simple graphics, it should run fine. Measures will be done on the Title screen.
• FTL: that I added to the bench after doing the QEMU measures. Measures will be done on the 1st Tutorial screen, while the game is paused.
• CINEBENCH r15: A benchmark based on a raytracing engine. Lots of SSE (SSE2 and more) code here. Use multi-core also. Does include a CPU bench and OpenGL bench, but only the CPU one is used here. It provides a simple number indicating the performance (the higher, the better).

To install WorldOfGoo, the “uname” trick will be used, as this allows to choose x86 or x86_64 installation (without the trick, the installer doesn’t recognise “aarch64” platform and fallback to x86). WorldOfGoo will run at 1920×1080 fullscreen.

CINEBENCH r15. This one needs Wine, and a 64bits version of it. It’s a benchmark with the CINEMA 4D Engine.

After some some testing, I realized that both openarena and WorldOfGoo mainly use x87 code, at least for the 32bits version of WorldOfGoo. Both QEMU and FEX seem to use use Softfloat for it, to keep the 80bits precision, while box uses hardware float (with some tricks to keep 80bits when needed, like on some data copy used by old games), so I decided to also check the menu page of FTL, that I know use SSE code. But I didn’t test on QEMU (it’s not hardware accelerated anyway, so it would be too slow). FTL will run at default resolution of 1280×720 windowed. I’ll launch the tutorial, answer to the 1st dialog box and mesure the fps at this point.

继续阅读Box86/Box64 vs QEMU vs FEX (vs Rosetta2)