逸

《/etc/systemd/system/cat-monitor.service》 # /etc/systemd/system/cat-monitor.service [Unit] Description=Cat Observation Daemon After=network-online.target Wants=network-online.target [Service] Type=simple User=yi WorkingDirectory=/home/yi/Observe/Cat/ ExecStart=/usr/bin/python3 /home/yi/Observe/Cat/monitor.py StandardOutput=journal StandardError=journal Restart=on-failure RestartSec=5s # 【Unit文件内嵌的“开发者笔记”】 # 1. 曾考虑用更高效的Go重写，但Python的快速原型能力更适合本探索性项目。 # 2. Restart=on-failure 确保服务因任何意外（如USB传感器松动）崩溃后，能自动重生。 # 3.详见yiblog.com 《catMonitor.py》(已保留主要逻辑部分) # catMonitor.py import time,logging,os,random from datetime import datetime class CatMonitor: def __init__(self): self.log_file = 'catMonitor.log' # 注：初始版本曾包含一个名为'emotionNum'的变量，已于v0.3.2中 移除。 # 理由：引入主观量化指标会污染观测数据的客观性。 self.setup_logging() def setup_logging(self): logging.basicConfig(filename=self.log_file, level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s') def read_infrared_sensor(self): # 传感器校准记录：2023-10-26，灵敏度下调至阈值85%。 # 【调整原因】v0.1时期，风卷起的塑料袋在晨间特定角度下会触发连续误报 （7次）。 # 系统在05:47-06:12期间，向我发送了5封“目标出现”的邮件。 # 那是一次失败的晨间唤醒协议。 return False # 模拟数据 def capture_camera_feed(self): date_dir = datetime.now().strftime("%Y-%m-%d") save_path = f"/home/yi/Observe/Cat/archive/{date_dir}/" os.makedirs(save_path, exist_ok=True) timestamp = datetime.now().strftime("%H%M%S") filename = f"{save_path}{timestamp}.jpg" if random.randint(1, 100) == 1: open(filename, 'w').close() return "EMPTY_FRAME" return f"FILE:{filename}" def send_email_report(self): # 邮件发送协议。当前版本：v1.2 # 版本历史： # v1.0：发送至工作邮箱。功能正常。 # v1.1：【错误配置】发件人字段被误设为“system@home”，而非“yi@desktop”。 # 导致邮件被公司服务器拦截，连续失败。 # v1.1在运行12小时后，因“smtp.ConnectError”异常而崩溃。 # 查错日志显示，它在深夜尝试重连了23次。 # v1.2：已修复。当前运行稳定174小时。 pass def run(self): last_report_time = time.time() # “空置时长”计数器。用于生成系统健康报告，与观测目标本身无关。 continuous_empty_hours = 0 while True: infrared = self.read_infrared_sensor() camera_analysis = self.capture_camera_feed() timestamp = datetime.now().strftime("%Y-%m-%d %H:%M:%S") if infrared: status = f"{timestamp} - 状态：活动确认 - 附加数据： {camera_analysis}" continuous_empty_hours = 0 # 计数器重置 else: status = f"{timestamp} - 状态：基线空置" continuous_empty_hours += 0.5 # 每30秒循环，故加0.5小时 logging.info(status) if continuous_empty_hours > 12: # 空置超12小时，触发资源优化逻辑 logging.info(f"{timestamp} - 系统提示：目标点位空置超12小时。") logging.info(f"{timestamp} - 建议：可考虑将巡检间隔从30秒调整至 300秒，以降低CPU占用率") # 注意：此处仅为日志建议，从未实际执行间隔调整。 # 附注：调整间隔可能导致错过目标出现的初始瞬间，不予采纳。 current_time = time.time() if current_time - last_report_time >= 3600: self.send_email_report() last_report_time = current_time time.sleep(30) if __name__ == "__main__": monitor = CatMonitor() monitor.run() yiblog.com/detail?num=4017 标题：为什么我坚持用python而非Golang 内容：重构为Go理论上至少节省15%的多核占用，但是最终决定不这么做，毕竟，这个项目本身不关乎效率，只是一个观测尝试。Python的异常处理和日志，也许更像我的呼吸？如果我把它打磨成一个高效沉默的黑盒，我就失去了理解自己为何观测的窗口 yiblog.com/detail?num=4023 标题：系统不再值得信任 内容：今日日志出现一条 附加数据：EMPTY_FRAME。这是本月第七次。图像文件存在，但大小为0字节。传感器、存储介质、文件系统权限、日志链路——一切可测指标均正常。 我排查了所有可能。这指向两种结论： 存在一个我尚未理解的、概率约为1%的硬件层面的量子隧穿效应或宇宙射线辐射错误，使图像数据在传入缓冲区前被擦除。 系统（或者说，世界）在特定瞬间，拒绝被记录。 我更倾向于相信后者。 这意味着我所有的观测、日志、分析，都建立在一个虚伪的共识上：即世界愿意被观测。当它偶尔不愿时，它就交给我一个0，一个空集，一个沉默的句号。 如果连一个/dev/video0的视频流都无法被忠实记录，那我凭什么相信，我能记录“猫今天是否快乐”，或者“那片朝霞在猫眼里究竟是什么颜色”？ 今晚，我停止了 cat-monitor.service。 不是通过 systemctl stop，而是用 kill -19。我不想让它优雅停止，我想让它暂停。就像世界对我做的那样。 systemctl status 会显示它 Active: inactive (dead)。 但我知道，它只是睡着了。和我一样。 作者附： 看，这个就是逸 他试图在为猫建立一个可观测，可记录，可分析的理性系统，却被一个空帧轻松击溃 Auburn在不可知中采集诗意。逸，则在不可知面前，遭遇了自身系统彻底的内存溢出。 我猜，如果让逸去分析你笔下那流转的眼睛，他的日志里大概只会留下一行： ERROR - 栈空间超过最高深度，内存分配重启失败，进程已中止 这或许就是我们故事的开端：一个因无法理解，而必须存在的对话