我有一个Windows的守护进程运行在一个Linux的酒盒和Xvfb。 由于这个相当实验性的设置，守护进程定期崩溃，我想实现某种机制来自动重启守护进程。 目前我有一个systemd单位定义与Restart=always设置。
不过，我注意到守护进程有时会崩溃，但不会退出进程。 这相当于显示一个对话框，问题是“守护程序已崩溃，是否要发送错误报告？”。 所以，进程仍在运行，但守护进程已停止工作。
这个现象的唯一的外部行为，我可以检查我的Linux机器上是两个新的文件，出现在某个位置，但具有可变的文件名（他们是时间依赖的，并在他们的名字有一个时间戳）。 我认为他们是某种内存转储或堆栈跟踪应该最初用于错误报告发送。
所以现在我正在寻找一个systemd来解决这个问题的解决scheme
我想了一个用bash写的包装器，但是有两个问题：首先我不知道如何实现这个行为，其次，这会使得systemd的使用完全过时，因为脚本处理所有的崩溃处理，systemd只会执行脚本。
我还想过，只是定期重新启动守护进程与systemd的给定的function，但这将是相当低效的（事实上，一个酒包装的Windows守护进程是不低效的，因为它会重新启动守护进程有时在没有必要的时候，或者在守护进程崩溃之后需要一些时间，直到定期重启。
什么是解决这个问题的最佳解决scheme？
只是为了logging：我所说的守护进程是Google照片的上传器。 谷歌因为某种原因没有为Linux发布。
好的，我发现了systemd.path的威力。
我用ExecStart=systemctl restart daemon.unit和Type=oneshot创build了第二个服务单元。 之后，我创build了第三个单元， PathModified=<crashdump output directory>和Unit=daemon-restart.unit PathModified=<crashdump output directory>的path单元。
它现在有效。 我只需要确保没有其他进程正在写入输出目录，但是这可以通过多个不同的wineprefix来解决。
我认为你的问题是你的程序可能会崩溃，但酒不是，所以系统没有看到任何错误（PID还在）。
首先，您可以在这个问题的答案中find一些帮助： 有条件地启动SystemD服务？
我认为你可能需要详细说明你的需求（和/或考虑调整它们以简化设置）。
基本上，我认为解决scheme可以归结为聪明地使用ConditionPathExistsGlob =，可能在一个辅助单元。
哈克解决scheme可能涉及一个具有这样的PathExistsGlob条件的定时器单元，可能会重新启动您的主要服务。 我倾向于希望让这个计时器单元也处理文件/转储的清理，而不是让主要单元这样做，但这几乎肯定是一个问题。
所以，我不会碰你所拥有的东西，而是添加一些像（注：这是一个猜测，没有testing）：
[Unit] Description=Detect and recover issues with Uploader After=uploader.service Requires=uploader.service PartOf=uploader.service AssertPathExistsGlob=/srv/uploader/crash*.dump [Service] Type=oneshot ExecStart=cleanup_script Restart=on-success
基本逻辑是：
我并不是说这是一个很好的解决scheme，但它可能是一个解决scheme