我正在从Windows服务(在python中创建,使用pyinstaller转换为exe并使用sc安装)启动Windows应用程序的python应用程序(使用pyInstaller创建的exe版本),但是我的应用程序生成的日志文件并没有旋转。
所以我实际上使用了logger.conf文件,该文件具有logger配置,带有rotationFileHandler,每10KB之后旋转文件一次(用于测试)。 conf文件中的配置如下所示:
...
[handler_fileRotationHandler]
class=logging.handlers.RotatingFileHandler
level=NOTSET
formatter=simpleFormatter
args=('<absolute path of log file>','a',10240,5)
...
内部python代码中,我正在使用此配置来创建和旋转日志文件。
以下是适当轮换日志文件的情况列表:
1-使用python命令开始的python版本
2- exe版本(使用PyInstaller创建)可以通过双击直接启动
3-从Windows服务启动的exe版本也以python创建,如果该服务是使用以下类似的python命令安装的:
MyService.py install
现在是当它不起作用的时候:
我将Windows服务代码转换为exe(再次使用pyInstaller),并使用以下命令通过sc安装该服务:
sc create MyService binPath= "<absolute path of service exe file>"
开始使用此服务时,应用程序运行正常,并且也生成了日志文件,但是在达到fileHandler中为日志定义的最大大小后,它不会创建另一个日志文件,因此仅在此处停留在日志方面。该应用程序可以正常运行,只是不会记录日志。
这是我尝试并观察到的内容:
1-在两种情况下,我都使用subprocess.Popen()命令启动了我的应用程序exe版本,并且我的应用程序没有任何UI元素,因此它可以在Windows会话0的后台完美运行。仅供参考,以备不时之需。
2-如果删除现有的日志语句和空的日志文件,则日志开始记录在文件中,并在达到最大大小时再次停止。
3-在两种情况下,我都使用os.getcwd()命令获取启动应用时运行的目录:
在使用python案例安装的python服务中,应用程序在“ C:\ Users \\ AppData \ Local \ Programs \ Python \ Python36 \ lib \ site-packages \ win32”中运行
在使用sc case安装的服务启动的exe版本中,应用程序在“ C:\ Windows \ system32”中运行
尽管在两种情况下,logging.conf文件都提供了日志文件的创建路径,所以我假设这应该没有任何问题(实际上,日志文件确实在预期的位置创建了,只是文件轮转不起作用,所以我想这不相关)
我只需要使用sc安装的exe版本,而不能使用python服务版本。如何解决这个问题,任何帮助或指导或指示,不胜感激。
答案 0 :(得分:0)
[供有兴趣了解解决方案的人]
因此,我面临的问题是RotationFileHandler中的一个常见问题,该问题是两个处理程序同时处理同一文件,从而阻碍了RotationFileHandler重命名已填充的日志文件。
要详细说明,我将异常处理放在handler.py的RotationFileHandler源代码中,并将异常打印在文件中。从那里我得到的问题是:
...
[WinError 32] The process cannot access the file because it is being used by another process: 'C:\\Users\\<path to log>\\test.log' -> 'C:\\Users\\<path to log>\\test.log.1'
...
在更多搜索中,我发现这是Windows记录器中FileRotationHandler的常见情况,由于多种可能的原因,有时会向同一日志文件打开多个句柄,因此,旋转文件处理程序无法重命名该文件。
stumbled upon this thread explaining many possible scenarios
我使用了procexp工具来检查我的日志文件是否具有多个句柄(由其他应用程序打开)。我发现,由于我对服务代码和应用程序代码使用了相同的logging.conf,因此它们都具有打开的句柄来记录两者的文件。我为服务代码创建了一个单独的配置文件,问题不再存在。 :)
我唯一不知道的是为什么这仅在服务和应用程序的exe版本中发生,而在python版本中却没有发生,因此理想情况下,当以python代码运行时,该问题也应该发生过。