为什么 docker mysql 建出来的 /var/lib/mysql 用户是 systemd-coredump
是 systemd-coredump 只是碰巧而已
因为 mysql 容器内的 mysql 用户 ID 是 999
1 2
# passwd in mysql container mysql:x:999:999::/var/lib/mysql:/bin/bash
而主机上的 999 为 systemd-coredump
1 2
# passwd on host systemd-coredump:x:999:997:systemd Core Dumper:/:/sbin/nologin
为什么 percona-xtrabackup 备份容器中的 mysql 显示无权限
1 2 3
2023-07-24T02:47:58.476552-00:00 0 [ERROR] [MY-012592] [InnoDB] Operating system error number 13 in a file operation. 2023-07-24T02:47:58.476735-00:00 0 [ERROR] [MY-012595] [InnoDB] The error means mysqld does not have the access rights to the directory. 2023-07-24T02:47:58.490978-00:00 0 [ERROR] [MY-013861] [InnoDB] Failed to list redo log files in the redo log directory ./#innodb_redo/
Warning: Some installed kegs have no formulae! This means they were either deleted or installed manually. You should find replacements for the following formulae: pycparser cffi erdtree
虽然没什么影响但看着不爽
可以通过brew untap homebrew/core解决
原因是
It removes the local copy of the tap repository (see manpage). This is fine if you do not work on the repository, because the default option since brew 4.0.0 is to fetch formulae information from the JSON API (see 4.0.0 release notes). If you run brew doctor, you should see that the homebrew/core tap has not been updated for a while.
大致就是走 JSON API 了，homebrew/core 也不维护升级了，所以本地那份也别留着了
结合了这两个设备的情况之后，再综合全屋的有线连接情况，我突然开窍的想到了换个网线。两个屋到交换机是我自己选的日线万兆，到每个屋的面板上，各做了一对日线的万兆模块。俩屋的 AP，直接在网线上做的头，很稳定。机柜里连 NAS 等的网线是 NAS 送的，两根做的聚合，也很稳定。现在最大的可能就是这几根《最后一米》，从模块到终端设备的秋叶原（CHOSEAL）七类扁平网线带镀金水晶头
voidrun(void){ constchar* addr = "127.0.0.1:8088"; acl::server_socket server; if (!server.open(addr)) { // Bind and listen the local address. return; }
while (true) { acl::socket_stream* conn = server.accept(); // Wait for connection. if (conn == NULL) { break; } std::thread thread([=] { // Start one thread to handle the connection. char buf[256]; int ret = conn->read(buf, sizeof(buf), false); // Read data. if (ret > 0) { conn->write(buf, ret); // Write the received data. } delete conn; }); thread.detach(); } }
target_link_libraries(test PUBLIC acl_all) target_link_directories(test PUBLIC $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/lib> $<INSTALL_INTERFACE:lib> )
target_include_directories(test PUBLIC $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include/acl-lib> $<INSTALL_INTERFACE:include/acl-lib> PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/src )
It appears that this escape key issue is caused by Siri. More specifically, this issue may occur when Siri freezes. To address this, force-quit Siri and ESC will start working again. Here is how:
On your Mac, open Activity Monitor (Applications > Utilities).