Sysmon service executable remains `(deleted)` after restart, causing repeated needrestart restarts and systemd start-limit-hit
@MarioHewardt 已经在做这个了。
开始于 2026年10月9日。
评估
这个 Issue 还没有评估数据。
描述
Describe the bug
On Linux with Sysmon for Linux 1.5.3, the Sysmon systemd service can remain running with its executable reported as deleted:
/proc/<PID>/exe -> /opt/sysmon/sysmon (deleted)
This causes needrestart to continuously identify sysmon.service as using an obsolete binary. When needrestart is invoked multiple times during an APT/dpkg transaction, it restarts sysmon.service repeatedly. Eventually, the systemd start limit is reached and Sysmon remains stopped (start-limit-hit).
Sysmon itself does not appear to crash in this scenario. The service restarts are initiated by needrestart. However, even after a successful restart, the newly started process again references /opt/sysmon/sysmon (deleted), so the condition is reproduced rather than resolved:
uses obsolete binary /opt/sysmon/sysmon
To Reproduce
-
Install Sysmon for Linux 1.5.3 using the official package.
-
Install and configure Sysmon normally, for example:
sudo /usr/bin/sysmon -accepteula -i /path/to/config.xml -
Verify that
sysmon.serviceis running:systemctl status sysmon.service -
Determine the main Sysmon PID:
pid=$(systemctl show sysmon.service -p MainPID --value) echo "$pid" -
Check which executable the process is using:
sudo readlink -v "/proc/$pid/exe"In the affected state, this returns:
/opt/sysmon/sysmon (deleted) -
Compare the running executable with the file currently present at
/opt/sysmon/sysmon:sudo stat \ -Lc 'device=%d inode=%i size=%s mtime=%y file=%N' \ "/proc/$pid/exe" sudo stat \ -Lc 'device=%d inode=%i size=%s mtime=%y file=%N' \ /opt/sysmon/sysmonThe running executable and the current
/opt/sysmon/sysmonfile have different inode numbers. -
Run
needrestartin list-only mode (does not change service state):sudo needrestart -v -r lneedrestartreports Sysmon similar to:[main] #<PID> uses obsolete binary /opt/sysmon/sysmon [main] #<PID> exe => /opt/sysmon/sysmon [main] #<PID> is sysmon.service Services to be restarted: systemctl restart sysmon.service -
Restart
sysmon.serviceand repeat the/proc/<PID>/execheck:sudo systemctl restart sysmon.service pid=$(systemctl show sysmon.service -p MainPID --value) sudo readlink -v "/proc/$pid/exe"The newly started Sysmon process can again be observed running from:
/opt/sysmon/sysmon (deleted)As a result, the next
needrestartinvocation identifiessysmon.serviceas requiring another restart.
Sysmon version
Sysmon v1.5.3 (official package, not built from source)
- Package-installed binary:
/usr/bin/sysmon - Installed/running copy:
/opt/sysmon/sysmon
Distro/kernel version
Distribution: Ubuntu 24.04.3 LTS
Kernel: 6.8.0-117-generic
Sysmon configuration
<Sysmon schemaversion="4.22">
<!--SYSMON META CONFIG-->
<!-- Both MD5 and SHA256 are the industry-standard algorithms for identifying files -->
<HashAlgorithms>md5,sha256,IMPHASH</HashAlgorithms>
<EventFiltering>
<RuleGroup name="" groupRelation="or">
<ProcessCreate onmatch="exclude">
</ProcessCreate>
</RuleGroup>
<RuleGroup name="" groupRelation="or">
<ProcessTerminate onmatch="include">
</ProcessTerminate>
</RuleGroup>
</EventFiltering>
</Sysmon>
Sysmon-generated systemd unit:
[Unit]
Description=Sysmon event logger
After=syslog.service
StartLimitBurst=5
StartLimitIntervalSec=90
[Service]
Type=forking
User=root
WorkingDirectory=/opt/sysmon
ExecStart=/opt/sysmon/sysmon -i /opt/sysmon/config.xml -service
LimitMEMLOCK=infinity
Restart=on-failure
RestartSec=10
Logs
2026-10-09T06:59:20.403364+02:00 systemd[1]: Stopping sysmon.service - Sysmon event logger...
2026-10-09T06:59:20.445529+02:00 systemd[1]: sysmon.service: Deactivated successfully.
2026-10-09T06:59:20.445707+02:00 systemd[1]: Stopped sysmon.service - Sysmon event logger.
2026-10-09T06:59:20.445752+02:00 systemd[1]: sysmon.service: Consumed 4min 28.179s CPU time, 245.4M memory peak, 0B memory swap peak.
2026-10-09T06:59:20.450398+02:00 systemd[1]: Starting sysmon.service - Sysmon event logger...
2026-10-09T06:59:21.310675+02:00 systemd[1]: Started sysmon.service - Sysmon event logger.
2026-10-09T06:59:24.355925+02:00 systemd[1]: Stopping sysmon.service - Sysmon event logger...
2026-10-09T06:59:24.397629+02:00 systemd[1]: sysmon.service: Deactivated successfully.
2026-10-09T06:59:24.398058+02:00 systemd[1]: Stopped sysmon.service - Sysmon event logger.
2026-10-09T06:59:24.406510+02:00 systemd[1]: Starting sysmon.service - Sysmon event logger...
2026-10-09T06:59:25.183633+02:00 systemd[1]: Started sysmon.service - Sysmon event logger.
2026-10-09T06:59:44.429904+02:00 systemd[1]: Stopping sysmon.service - Sysmon event logger...
2026-10-09T06:59:44.470696+02:00 systemd[1]: sysmon.service: Deactivated successfully.
2026-10-09T06:59:44.470933+02:00 systemd[1]: Stopped sysmon.service - Sysmon event logger.
2026-10-09T06:59:44.471028+02:00 systemd[1]: sysmon.service: Consumed 2.076s CPU time, 118.6M memory peak, 0B memory swap peak.
2026-10-09T06:59:44.476431+02:00 systemd[1]: Starting sysmon.service - Sysmon event logger...
2026-10-09T06:59:45.252204+02:00 systemd[1]: Started sysmon.service - Sysmon event logger.
2026-10-09T06:59:47.389335+02:00 systemd[1]: Stopping sysmon.service - Sysmon event logger...
2026-10-09T06:59:47.424445+02:00 systemd[1]: sysmon.service: Deactivated successfully.
2026-10-09T06:59:47.424675+02:00 systemd[1]: Stopped sysmon.service - Sysmon event logger.
2026-10-09T06:59:47.429363+02:00 systemd[1]: Starting sysmon.service - Sysmon event logger...
2026-10-09T06:59:48.290707+02:00 systemd[1]: Started sysmon.service - Sysmon event logger.
2026-10-09T06:59:50.438518+02:00 systemd[1]: Stopping sysmon.service - Sysmon event logger...
2026-10-09T06:59:50.472584+02:00 systemd[1]: sysmon.service: Deactivated successfully.
2026-10-09T06:59:50.472742+02:00 systemd[1]: Stopped sysmon.service - Sysmon event logger.
2026-10-09T06:59:50.474697+02:00 systemd[1]: Starting sysmon.service - Sysmon event logger...
2026-10-09T06:59:51.386434+02:00 systemd[1]: Started sysmon.service - Sysmon event logger.
2026-10-09T06:59:53.579936+02:00 systemd[1]: Stopping sysmon.service - Sysmon event logger...
2026-10-09T06:59:53.621050+02:00 systemd[1]: sysmon.service: Deactivated successfully.
2026-10-09T06:59:53.621271+02:00 systemd[1]: Stopped sysmon.service - Sysmon event logger.
2026-10-09T06:59:53.621537+02:00 systemd[1]: sysmon.service: Start request repeated too quickly.
2026-10-09T06:59:53.621545+02:00 systemd[1]: sysmon.service: Failed with result 'start-limit-hit'.
2026-10-09T06:59:53.621652+02:00 systemd[1]: Failed to start sysmon.service - Sysmon event logger.
Expected behavior
After a successful restart of sysmon.service, the running Sysmon process should reference the current executable in a way that does not cause service/restart monitoring tools such as needrestart to immediately consider the newly started service obsolete again.
At minimum, repeatedly restarting an otherwise healthy sysmon.service should resolve the stale executable condition rather than reproduce it.
Additional context
Environment
- needrestart 3.6, integrated with APT/dpkg (
DPkg::Post-Invoke)
Additional observations
The package-managed binary and the copy under /opt/sysmon were compared:
sha256sum /usr/bin/sysmon /opt/sysmon/sysmon
cmp -s /usr/bin/sysmon /opt/sysmon/sysmon && echo IDENTICAL
Both files were identical in the observed case.
The Sysmon process command line was:
/opt/sysmon/sysmon -i /opt/sysmon/config.xml -service
The main process therefore remains associated with the Sysmon service invocation while the executable referenced through /proc/<PID>/exe has already been replaced or deleted.
Impact
On systems where needrestart is integrated with APT/dpkg, repeated DPkg::Post-Invoke executions can result in the following sequence:
Sysmon running
-> executable reported as deleted
-> needrestart detects obsolete binary
-> needrestart restarts sysmon.service
-> Sysmon executable is again reported as deleted
-> next needrestart run detects it again
-> another restart
-> ...
-> systemd start limit reached (StartLimitBurst=5, StartLimitIntervalSec=90)
-> start-limit-hit, sysmon.service remains stopped
Workaround
Prevent needrestart from automatically restarting sysmon.service while still allowing it to report the obsolete executable, e.g. via override_rc:
$nrconf{override_rc}{qr(^sysmon\.service$)} = 0;
This avoids the restart loop, but does not resolve the underlying Sysmon executable lifecycle behavior.
Related issue
- #177:
/opt/sysmon gets removed on upgrade in RHEL8/RHEL9/Ubuntu20.04
The issue described here appears different: Sysmon starts successfully, but the running service subsequently references /opt/sysmon/sysmon (deleted), which causes needrestart to repeatedly consider the service obsolete.
- 主要语言
- C
- 星标
- 2.2k
- 派生
- 222
- 平均合并
- 4 小时 50 分钟
- 30 天内合并 PR
- 3
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
microsoft/Sysmon-Linux 的其他 Issue
-
难度 3/5 1-2 天 新手友好度 68/100
microsoft/Sysmon-Linux#253 ·
-
难度 3/5 1-2 天 新手友好度 72/100
microsoft/Sysmon-Linux#252 ·
-
难度 3/5 1-2 天 新手友好度 55/100
microsoft/Sysmon-Linux#247 ·
-
难度 1/5 1 小时以内 新手友好度 12/100
microsoft/Sysmon-Linux#246 · 3 条评论 ·
-
ProcessTerminate events intermittently report an unrelated user's UID instead of the terminating process's UID可能已有人在做 @MarioHewardt 于 111 天前认领。 未关闭
microsoft/Sysmon-Linux#238 · 已指派 1 人 ·
查看 microsoft/Sysmon-Linux 的全部 Issue
相似的 Issue
-
enhancement good first issue help wanted
难度 2/5 1-3 小时 新手友好度 82/100
-
bug multiplayer status: planned
难度 2/5 1-3 小时 新手友好度 67/100
ChupathingyCE/chupathingyce#851 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 73/100
HigherOrderCO/Bend#2104 ·
-
research-radar
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
good first issue help wanted program
难度 2/5 1-3 小时 新手友好度 83/100
hffgzktbcc-blip/ounce-core#297 ·
维护者通常 1 天内回复