【问题标题】:Windows Service not working as expectedWindows 服务未按预期工作
【发布时间】:2014-05-20 15:51:29
【问题描述】:

我有一个 Windows 服务,它轮询文件位置,当找到一些需要的文件时,它会发送电子邮件。这项服务已经上线了很长一段时间,并且一直运行良好,直到上周它陷入了混乱。

维护了一个日志来捕获移动到该位置的文件。当文件移动到该位置时,会在日志文件中创建一个条目。此外,当满足条件并发送邮件时,日志文件中也会有一个条目表明邮件已发送。同样,在启动或停止服务时进行条目。

自上周以来,该服务无法正常运行。没有邮件正在发送。我检查了 SMTP 服务器,那里一切正常(由 SMTP 团队确认)。我检查了日志,发现这些条目没有被记录。即使文件被移动到该位置,它也不会被记录在日志中。

我想不出任何理由。我尝试过多次重启服务。

EDIT1

更多信息:

Windows 服务是基于 FileWatcher 的服务。

EDIT2

一直以来,我一直在使用共享路径来轮询文件。我尝试在 3 个不同的服务器上使用相同的路径。结果相同。然后我尝试使用本地路径(服务器 F 驱动器上的路径),它按预期工作。但我仍然需要能够在共享路径中做到这一点。一直以来唯一的共同点就是共享路径!

【问题讨论】:

  • 听起来像一个安全问题,有人在任何地方更改权限吗?
  • 信息这么少,很难提供帮助。例如,您正在谈论的服务的名称是什么。你有什么错误信息吗,...
  • 没有记录错误信息。服务名称是 Email_Tool

标签: .net service windows-services


【解决方案1】:

如果您没有更改代码,则问题是环境问题。最大的环境因素是运行 Windows 服务的用户帐户权限。如果是域账户,对磁盘的 IO 是否仍然有效?如果是本地帐户,是否更改了本地帐户策略以防止 IO ?您能否检查您正在使用的文件系统上的有效权限,以确保 Windows 服务执行帐户具有正确的权限?

最后一件事(与您的问题没有直接关系)我已经为其他目的编写了一个相同的实用程序,因此请注意 FileSystemWatcher 不提供有保证的服务;在某些情况下,单个文件通知会转换为通用的“某些文件已更改”通知,并且在网络上的共享驱动器上并不那么可靠。使用轮询任务可能更可靠,因为您至少可以在查找更改时记录任何权限异常 - 目前我猜您根本没有收到通知并且您不知道为什么。

【讨论】:

    猜你喜欢
    • 2017-10-21
    • 1970-01-01
    • 2019-06-02
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2022-08-17
    • 1970-01-01
    相关资源
    最近更新 更多