“非监听”模式讨论，调用之后触发一次事件，不进入等待并立刻退出

[crazywhalecc]

因为如果整合 WebHook 的话，非 Docker Compose 环境的后端在对接 watchvuln 的时候还需要守护 watchvuln 的进程，同时如果 webhook 调用失败会直接退出。如果由后端调用 exec 执行一次 WebHook，或者仅在需要更新的时候调用更新一次库，可以大幅减少爬取的频率，同时也可以避免后端偶尔挂起导致 watchvuln 的反复异常退出。

[zema1]

watchvuln 执行过程分成两步：初始化数据库，然后定期检查漏洞增量并推送。你说的这个情况初始化数据库什么时候做呢。

另外 watchvuln 初始化完成后是不应该异常退出的，可能是由 bug

[zema1]

我修了一个问题，可能和这个异常退出有关，可以看看能否满足需求。不能的话可以再开 issue

[crazywhalecc]

你说的这个情况初始化数据库什么时候做呢。

简单来说就是初始化完成后只检查一次漏洞（1. 初始化数据库，2. 检查一次漏洞增量并推送，3. 退出程序），如果成功推送就正常退出（exitcode=0）。假设实现是通过某个参数 --no-loop 来实现，这时候检查周期参数 INTERVAL 是无效的。就是让 watchvuln 更像是一个一次性的数据库更新和推送命令，而不是守护进程。

如果实现起来比较麻烦的话，那就忽略我这个奇特的需求吧 👀 ，主要是再挂一个服务可能维护起来总得考虑它，原本是想把 watchvuln 当作现有程序的的一个子模块的。

[zema1]

这里的关键在于，没法在一次调用里完成 初始化数据库 和 漏洞增量检查 两件事。这两件事是冲突的，因为初始化数据库会把当前的所有漏洞都入库，也就没有漏洞“增量”了。watchvuln 里的漏洞增量是因为只初始化一次，后面是循环任务来和上一次的状态进行 diff 才有了增量漏洞。

所以，你的需求实际是将 watchvuln 的两个阶段自行拆开运行，这个我建议通过代码调用实现。可以参考 main.go 的逻辑。

实际上，我预期的 watchvuln 本身就是一个稳定的服务，它是可靠的，应该可以直接作为一个子模块的。如果想降低爬取频率，增大 INTERVAL 即可。异常退出之类的问题都会在主线被修复掉。

[crazywhalecc]

这里的关键在于，没法在一次调用里完成 初始化数据库 和 漏洞增量检查 两件事。这两件事是冲突的，因为初始化数据库会把当前的所有漏洞都入库，也就没有漏洞“增量”了。watchvuln 里的漏洞增量是因为只初始化一次，后面是循环任务来和上一次的状态进行 diff 才有了增量漏洞。

是的，如果库是空的，或者表是空的，它不会提醒。目前看数据表结构似乎它缺少一个独立的状态记录，是直接依靠数据表来比对数据的，也就是理论上在服务形态运行 watchvuln 才是可靠的。

另外，我上面提到的异常退出问题解释：假设 webhook 地址在启动 watchvuln 时是无效的，即发送 watchvuln-initial 事件时失败，就会直接退出，没有重试连接等操作。（因为我目前的环境部署服务比较麻烦，所以只能在运行一段时间后杀死进程再次运行，所以有这个问题。下图是在 Windows 上复现的报错截图，仅作示例）

[zema1]

明白了，这个退出是预期的，从 watchvuln 的角度来看，发送的第一个测试性质的消息是需要成功的，表示链路正常跑通，否则希望用户能尽快地发现问题并解决，后面再推送时哪怕有错误也不会退出了。本质上时场景不太一样。