以前经常看到别人说鬼压床，但是自己从来没有经历过，也许有？但是自己忘记了。
上周在村里睡午觉，大概是到点了，迷迷糊糊中感觉自己醒了，于是想抬手拿起手机看看。结果发现左手完全抬不起来，我确认了一遍大脑发送了抬手的指令。但是眼里左手还放在身边。
我觉得可能是左手睡麻了，于是决定用右手抬一下左手，结果右手好像也没反应。再细细一体会，发现完全没有任何细节，看来还是在做梦，于是又沉沉睡去，大概过了一会会就醒了，却依然记得这部分内容，非常清楚。
但是除此之外没什么特别的，和其他的梦好像没区别，可能是因为自己没有惧怕的感觉吧，躺在床上动不了完全不会比在梦里把下午要上班的班上完了结果醒来发现还要上班的感觉更糟。

前几个月还有一次，睡觉的时候感觉完全喘不上气，感觉什么东西压到胸口了，在梦里好像快濒死了，可是一直又醒不过来，在梦里想了一会感觉自己起来大概被什么压到了，就开始疯狂扭动自己的身体，结果就清醒了。等醒来才发现老婆把大腿压我胸口上了，怪不得喘不上气，她还笑我一直扭动。

这个月一直用手环跟踪自己的睡眠数据，发现心率和呼吸速率几乎不怎么变动，所以如果呼吸有变化的话身体肯定会非常敏感，因为梦会把自己的感觉放大很多倍。

今天老婆给我说wireguard用不了了，测试一下才发现是域名过期了，这个十年前注册的域名昨天就已经过期了。
没有续期的原因就是这个域名没承载什么业务，唯一用到的地方就是ddns，因为我用dnspod解析，现在不实名已经无法用dnspod的任何业务了。
等过一阵子把手里的域名都转移到dynadot，续费便宜多了。

Name: chkjxcn.org
Internationalized Domain Name: chkjxcn.org
Registry Domain ID: The RDAP server redacted the value
Domain Status:
clientTransferProhibited

autoRenewPeriod

Nameservers:
ns1cnb.name.com

ns2qvz.name.com

ns3cna.name.com

ns4bty.name.com

Dates
Registry Expiration: 2027-01-18 17:01:39 UTC
Registrar Expiration: 2026-01-19 00:01:39 UTC
Updated: 2026-01-20 03:19:48 UTC
Created: 2016-01-18 17:01:39 UTC

ipfw是freebsd默认的防火墙，我利用它来进行流量分流，以及做user defined路由，在利用ipfw分流的文章中有描述。

平时用这一套东西的时候没什么问题，诡异的是只要一重启，ipfw就失效了。但是重启一下ipfw，有可以了。这个问题很久以前就出现了，只是因为系统重启次数比较少，所以不太影响业务。

今天南方电网又因为欠费拉闸了，同样的问题再次出现，我远程登陆进去看，以前我一直以为是接口重启导致ipfw转发错误，这次进去看，才发现ipfw没有处理任何报文，所有的ipfw packet counter都为0，问了deepseek后，他建议我检查net.inet.ip.fw.enable是否为0，检查后确实发现是0。

问题的关键在于这个值为什么是0，在初始化ipfw规则的脚本里有service ipfw restart，添加调试代码后，发现确实在这句执行后sysctl里的值变成0，可是内核没有任何错误信息打印。

因为这个enable其实是一个hookcall，所以很有可能在服务重启的过程中，函数执行出错，因此就把它设置成0了。不过我还是很好奇到底为什么会这样，等过两天回家再调试一下。

总结就是，ai总是能以旁人的眼光看到自己没看到的东西，我一直相信ipfw绝对是启用了，问题可能是rule没有完全生效或者因为keep-state。

============
找到原因了，因为是在/etc/rc.local中调用脚本，并且在脚本中service ipfw restart，但是sh的echo会返回2，如果stdout无法输出。这就导致ipfw_start返回2，而后面的ipfw_poststart便不会执行，而sysctl值就是在这里设置的。

stdout无法输出的原因是在rc.local中使用了后台执行，导致rc.local退出后，stdout被关闭，但是后台还在执行，此时echo失败，在运行命令前把stdout重定向到/dev/console就没有这个问题了。

由此可见，软件工程的安全边界，令人难以想象的小，甚至某些测试没有任何问题的东西，稍换一个环境，就会出莫名其妙的问题，让人百思不得其解。日志和debug消息，才是你的傍身利器，即使当下看起来没什么用。

2025年过去了，总结一下2025年做了什么。

今年上半年好像没有什么变动，也许是过太久不太记得了，主要是出去玩，五一的时候去赶海好几次，也去万泉河漂流，还有去潭门吃海鲜。
七月的时候去新加坡，没什么感悟，也就是到处逛逛，除了靠左不太适应，去超市和吃饭的店里大部分都能讲中文。
今年下半年改变了作息，现在工作日都是七点多就起床了，晚上就算睡的晚按时起来白天也不是很困，不再熬夜之后感觉身体变得更健康了，而且有更多的时间工作学习了。
当然最大的改变也是阅读了德宝法师写的禅修三部曲，也许我不会进行禅修，但是随时随地我都能练习我之所为我，专注于自己做的事情，以前经常抗拒的事情，也没那么讨厌了。
希望自己在新的一年能变得更好。

这两天，客户的机器上面的fail2ban一直启动失败，启动的时候显示connection refused。把能打开的loglevel都打开，依然只是显示同样的错误，没有更详细的显示。调试到一半时间，客户等不及了，同事便建议重启试试，我思考了一会，虽然重启大概率无法解决这个问题，不过依然可以试试。于是我同意重启，令人惊奇的是，重启后恢复正常。

第二天下午，同事在IM里喊“... that fail2ban issue happened again...”，于是我再继续昨日未完成的调试，调试的首要目的只是找到这个打印错误地方。搜索代码发现是个捕捉exception的地方，但是fail2ban把堆栈信息都丢弃了。我添加了traceback.print_exc来打印堆栈，结果发现是fail2ban连接syslog的unix domain socket失败，它会根据系统的类型来寻找对应的文件路径。在linux下，它会连接到/dev/log来输出日志，但是由于syslog没有启动，所以/dev/log并不存在。后续就是研究为什么syslog为什么crash了，不过和这个问题无关了。

这里有几个想到的问题：

1. 如何在没有堆栈的情况下有效输出日志？比如不显示connection refused，而是syslog socket connection refused？
   在try catch这个架构里感觉很难做到，exception在返回上层函数的时候，丢失了中间的信息，比如这里，socket的exception没有被logger处理，所以原样返回到fail2ban，fail2ban也不知道这个exception从哪里来的，所以也只能原样显示。
   因此这条log只能显示socket连接失败，并不能找到是哪个功能连接socket。
   如果然exception往上传递的时候携带更多信息呢，比如在logger里catch并且增加一条message到exception，这个感觉有点像golang的error设计，返回error的时候进行二次包装，给它更多信息。但是python可以在try catch中直接打印堆栈信息，有堆栈就基本能知道是哪里有错误了。
   所以exception发生的时候不应该只print一条消息，增加堆栈消息也是很有用的。
2. 为什么linux默认的syslog的socket是/dev/log，如果是有log设备那么很正常，由内核监听，但是这个是syslog创建的，用户态程序却在devfs监听，感觉有点不合理，如果syslog想要接收devfs挂载之前的日志呢？而且devfs通常可以mount多次，里面的socket文件却不能直接复制。