我在为 Redmine（或“|cat > /tmp/temp”）设置简单管道时遇到问题
/etc/postfix/虚拟：
support@myhost.com support
/etc/postfix/别名：
support: "|/opt/redmine-1.2.2/processemail.sh"
主文件
virtual_alias_maps = hash:/etc/postfix/virtual, mysql:/etc/postfix/mysql_virtual_forwards.cf
virtual_mailbox_domains = myhost.com, mysql:/etc/postfix/mysql_virtual_domains.cf
virtual_mailbox_maps = hash:/etc/postfix/virtual_alias, mysql:/etc/postfix/mysql_virtual_mailboxes.cf
alias_maps = hash:/etc/postfix/aliases
alias_database = $alias_maps
处理email.sh：
#!/bin/sh
/opt/redmine-1.2.2/extra/mail_handler/rdm-mailhandler.rb --url http://myhost.com --key f5obfctmGfqZWnOWNtR8 --project test --tracker support --allow-override tracker,project --verbose --unknown-user accept --no-permission-check
我已经跑了newaliases; postmap virtual; postalias aliases; postalias virtual_alias; newalias- 是的，可能跑得过头了，但仍然错过了 :(
我已经运行了 newaliases 并重新启动了 postfix。邮件照常投递，但没有添加任何内容到 /tmp
这是唯一关于virtual.
Dec 10 04:08:41 master postfix/virtual[3112]:
A3F46AD1BF: to=<support@myhost.com>, relay=virtual, delay=0.4,
delays=0.38/0.01/0/0.01, …这看起来与Windows Server 2022 时间服务跳跃到未来是同一问题。我还在 Microsoft（反馈中心）添加了针对该问题的支持票： https: //aka.ms/AAkwnpl
由于系统时钟对于正确工作的软件至关重要，并且可能是最核心的共享可变状态，因此这个问题对我们的系统和与我们通信的每个人都造成了严重破坏，并一直波及关键基础设施。
我们于 2022 年 8 月在 2019 年的服务器上首次注意到这一点。时钟原定为 2023 年 1 月，但后来自行修正。不幸的是，这是在日志被清除一段时间后发现的，因此我们无法进一步调试它。
但上个月，我们再次体验了它，这次是在 2016 年的服务器上。时钟被设置为未来 55 天。
15 秒后，时间服务注意到时钟与我们的域控制器不同，并且它必须将时钟调回 -4454176 秒。它会后退，因为它大于 4294967295。
第一次更改后 15 分钟，时钟再次设置，这次倒退到未来的 12 小时 26 分 43 秒。
第二次更改后 15 秒，计时服务注意到时钟已关闭，这次修正了它，因为它在合理的窗口内。
三周后，同样的事情在同一台服务器上再次发生，只是细节有所不同。与此同时，服务器已重新启动并更新了新的每月更新。
我们使用 VMWare，配置了两个物理硬件时钟。我们有两个配置为使用 pool.ntp.org 的域控制器——可能应该移动到我们自己的 stratum 0 硬件，尽管它可能与我们的问题无关。
在一些外部专家的帮助下，我们几乎排除了错误配置、手动干预（错误、安全漏洞或不忠诚的员工）和硬件问题，并且留下了“奇怪的 Windows 错误”。
不幸的是，2016 年并没有包含与这些事件相关的太多细节，因此很难进一步调试。2019+ 包含更多信息。
Windows Server 2022 时间服务中的 @chris1out跳转到未来对于未在域中注册的服务器也存在同样的问题，因此我们可以排除域控制器。它还使用标准时间服务器而不是 pool.ntp.org。这意味着我们也可以排除这两者。这几乎留下了时间服务中的错误作为可能的原因。这个服务器故障问题是我们能够找到的唯一有记录的事件。