结合了这两个设备的情况之后，再综合全屋的有线连接情况，我突然开窍的想到了换个网线。两个屋到交换机是我自己选的日线万兆，到每个屋的面板上，各做了一对日线的万兆模块。俩屋的 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).
# Download the binary for your system sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
# Give it permissions to execute sudo chmod +x /usr/local/bin/gitlab-runner
# Create a GitLab CI user sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
# Register runner sudo gitlab-runner register
# Install and run as service sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner sudo gitlab-runner start
注册过程中的 url, token 皆可在 Specific runners 中查看，其它需要关注的有
When using pinentry, you must have the proper permissions of the terminal device (e.g. /dev/tty1) in use. However, with su (or sudo), the ownership stays with the original user, not the new one. This means that pinentry will fail with a Permission denied error, even as root.
realStorageUnits controlls how the agent reports hrStorageAllocationUnits, hrStorageSize and hrStorageUsed in hrStorageTable. With this option set to ‘0’, the agent re-calculates these values for big storage drives with small allocation units so hrStorageAllocationUnits x hrStorageSize gives real size of the storage. Example: Linux xfs 16TB filesystem with 4096 bytes large blocks will be reported as hrStorageAllocationUnits = 8192 and hrStorageSize = 2147483647, so 8192 x 2147483647 gives real size of the filesystem (=16 TB).
Setting this directive to ‘1’ (=default) turns off this calculation and the agent reports real hrStorageAllocationUnits, but it might report wrong hrStorageSize for big drives because the value won’t fit into Integer32. In this case, hrStorageAllocationUnits x hrStorageSize won’t give real size of the storage.