rix的笔记

博客

  • Openclaw 配置踩坑

    sandboxing

    关于agent.id=main

    我喜欢使用docker来部署，防止失控， 默认的openclaw.json配置中关于agent.defaults.sandbox.mode默认为”non-main”, 如果同时设置了sandbox.workspaceRoot目录，然后在agent.id=”main”中同时设置了workspace目录位置。 我的本意是，agent为main的，都使用这个指定的workspace目录。如果使用docker部署，同时在不同的聊天渠道下，有时候会 把sandbox.workspaceRoot/session 下的目录作为workspace目录，从而整个错乱了。

    openclaw给出的解释: 

    根据 OpenClaw 文档和 schema 设计：
sandbox.mode: "non-main" 表示：非 main agent 的会话默认启用沙箱，main agent 默认不启用。
这是一个全局默认值（fallback），不是强制规则。
矛盾点：为什么 main agent 在沙箱里？
因为 OpenClaw 的运行时逻辑是：
sandbox.mode: "non-main" = 除了 main 以外的 agent 默认进沙箱。但 Gateway 本身是否把 main 也放进沙箱，取决于 agents.defaults.sandbox 的其他字段（如 workspaceRoot、docker.image 等）是否存在。
当 defaults.sandbox 块完整存在（有 workspaceRoot、browser.allowHostControl 等），Gateway 会把它当作一个有效的沙箱配置模板，即使 mode 是 "non-main"，main agent 如果也被 Docker 包装了，就会继承这个模板。

    因此，对于agent.id=”main”的配置，如果不使用sandbox的话（即使它真的运行在docker中）， 依然要配置”sandbox”: { “mode”: “off” } 来覆盖默认值。

    关于sandbox.backend=ssh

    我的两个agent(test1, test2), 两个配置基本一致，通过backend=ssh连接到其他的服务器（也是docker构建的，主要是因为默认的docker沙箱无法打开端口和高权限操作），然后我在同一个matrix房间中，分别询问这两个agent 的workspace的全路径， 然后，一个告诉我在/workspace，一个告诉我在/workspace/<session-id>/workspace, 最后让openclaw查询官方文档才找出区别:

    字段 test1 test2
    sandbox.workspaceAccess “rw” “none”（默认）
    工作区挂载点 /workspace /workspace/<session-id>/workspace

    完全是workspaceAccess模式的不同

  • docker 容器禁止生成core文件

    这个生成真的很烦，除特定之外，基本无太大用途。还占用空间，我自动备份每次都要备份这种无用的垃圾。

    1. docker-compose 方式:

    services:
  your_service:
    image: xxx
    ulimits:
      core: 0
    1. docker run 方式:

    docker run --ulimit core=0 ...
    1. 主机全局关闭: /etc/security/limits.conf 文件加入

    #+begin_example

  • sas3008 读取HBA温度

    ./storcli64 /c0 show all

    其中有一段： ROC temperature(Degree Celsius) = 59

    这个为芯片温度。就是不知道是背板的温度还是HBA的温度

  • bcachefs 关于reconcile pengding的消除

    先说故障过程：

    1. 我将bcachefs（EC） 由 replicas=2 更改为replicas=3， 这样相当于从raid5升级到raid6.
    2. 升级非常的慢，然后我删除了所有的文件，重新从备份系统复制回来，这样会比直接升级快很多
    3. 我的SSD由256G（NVME）+128G（SATA）+（80G PART）组成的cache。因为我要将80G的分区做他用，因此移除了它.然后reconcile就显示大约有65G的meta属于pending状态
    4. 我将meta_replicas更改为了2， 依然如此。
    5. 接下来发现，每次加载的时候，都会有一个大约4-5分钟的检查
    6. 接下来的重点是：随着使用的时间越来越长，ssd中need_discard会越来越多，从不减少，如果cache部分满了之后，速度会暴降。重新挂载后need_discard部分就会消失。

    原因： 移除80G分区后，文件系统的meta数据无法满足meta_replicas=3的分布，因此就只能在pending状态了。即使修改了meta_replicas=2, bcachefs依然尝试从不存在的地方先读取再减少。

    解决方式： 添加一个临时的设备到cache组，然后等着reconcile完成meta_replicas=3降级到meta_replicas=2的操作，完成后，再移除临时设备。 接下来 need_discard 就不会发生之前从不减少的问题了。

  • bcachefs 文件系统修改fs_label

    bcachefs 在format的时候可以指定fs_label， 其他时候没看到可以修改的地方。 从https://www.reddit.com/r/bcachefs/comments/1org1vh/how_to_change_label_to_bcachefs_partition/ 看到的一段脚本 

    #!/usr/bin/env python3
import fcntl
import os
import array

# Correct ioctl constants
FS_IOC_GETFSLABEL = 0x81009431
FS_IOC_SETFSLABEL = 0x41009432
FSLABEL_MAX = 256

def get_filesystem_label(mount_point):
    """Get filesystem label using FS_IOC_GETFSLABEL ioctl"""
    label_buffer = array.array('b', b'\x00' * FSLABEL_MAX)
    fd = os.open(mount_point, os.O_RDONLY)
    try:
        fcntl.ioctl(fd, FS_IOC_GETFSLABEL, label_buffer, True)
        label = label_buffer.tobytes().rstrip(b'\x00').decode('utf-8')
        return label
    finally:
        os.close(fd)

def set_filesystem_label(mount_point, label):
    """Set filesystem label using FS_IOC_SETFSLABEL ioctl"""
    if len(label) >= FSLABEL_MAX:
        raise ValueError(f"Label too long (max {FSLABEL_MAX - 1} chars)")

    label_bytes = label.encode('utf-8') + b'\x00'
    fd = os.open(mount_point, os.O_RDONLY)
    try:
        fcntl.ioctl(fd, FS_IOC_SETFSLABEL, label_bytes)
        return True
    finally:
        os.close(fd)

# Example usage (requires root/CAP_SYS_ADMIN)
if __name__ == "__main__":
    mount_point = "/mnt/old_fs_name"
    NEW_FS_NAME = "praxis"

    # Set label
    set_filesystem_label(mount_point, NEW_FS_NAME)

    # Get label
    current_label = get_filesystem_label(mount_point)
    print(f"Current label: {current_label}")