web-dev-qa-db-fra.com

Pourquoi mon service Windows n'écrit-il pas dans mon fichier journal?

J'ai un service Windows et utilise nlog pour la journalisation. Tout fonctionne bien lorsque je cours depuis le studio visuel. Le fichier journal est mis à jour sans problème. Lorsque j'installe le service, le service fonctionne correctement mais le fichier journal ne se met jamais à jour. Je cours sous service local si cela aide. Oui, j'ai créé le répertoire logs sous mon dossier d'application.

 <?xml version="1.0" encoding="utf-8" ?>
 <nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >

  <targets>
    <target name="file" xsi:type="File" fileName="${basedir}/logs/${shortdate}_info.txt"
            layout="${date} ${logger} ${message}" />
  </targets>

  <rules>
    <logger name="*" minlevel="Info" maxlevel="Info" writeTo="file" />
  </rules>
</nlog>
24
Mike Roosa

Votre compte de service local n'a pas accès à l'écriture dans l'emplacement de fichier spécifié. Vous le configurez pour utiliser un compte système dans l'onglet "Connexion" de la boîte de dialogue des propriétés du service. Vous pouvez également configurer le compte d'utilisateur dans le cadre du processus de configuration.

9
Michael Meadows

J'ai eu ce problème aussi. Comme mentionné par genki, vous vous connectez probablement au répertoire\Windows\System32. Peut-être vérifiez-vous le fichier journal que vous attendez en premier. Lors de l'écriture de services, j'ai souvent mis une ligne comme celle-ci au début pour que le répertoire actuel se comporte comme une application normale

Directory.SetCurrentDirectory(AppDomain.CurrentDomain.BaseDirectory);
29
Tim Clem

Si vous utilisez une version x64 de Windows, le fichier journal est enregistré dans le dossier C:\Windows\SysWOW64.

C'est le cas par défaut si vous générez votre projet à l'aide de AnyCPU configuration et le déployez sur un système d'exploitation 64 bits.

11

Vous pouvez utiliser Process Monitor pour examiner les opérations sur les fichiers en cours d’exécution et déterminer pourquoi elles échouent.

Je soupçonne (avec d'autres répondeurs) qu'il s'agit d'un problème de permission, le compte du service n'ayant pas suffisamment accès au fichier.

2
Richard

J'ai trouvé ce post très utile quand j'ai eu le même problème:

http://nlog-forum.1685105.n2.nabble.com/Nlog-not-working-with-Windows-service-tp6711077p6825698.html

En gros, vous voudrez inclure $ {basedir} dans l’emplacement de votre fichier dans votre configuration. Cela fera démarrer NLog à l’emplacement de votre exécutable.

2
bressain

Je viens d'avoir le même problème avec la journalisation de l'infrastructure d'entreprise.

Pour conclure cette question dont les réponses ensemble racontent la bonne histoire.

Dans votre exemple, lorsque vous utilisez Visual Studio IDE, le fichier journal est écrit en utilisant les autorisations utilisateur de l'application et le fichier journal est en cours d'écriture.

Le service Windows ne dispose pas de ces mêmes autorisations, de sorte que le fichier journal ne sera pas écrit. Le service Windows a l'autorisation (j'ai testé cela) d'écrire sur le 

AppDomain.CurrentDomain.BaseDirectory

utilisant l’espace de noms System.IO.

Donc dirigez le fichier journal vers ce répertoire de base et vous serez en sécurité. 

1
peterincumbria

Juste par curiosité, avez-vous vérifié si quelque chose est écrit dans le répertoire system32 de votre installation Windows? Iirc, c'est le répertoire de base d'exécution par défaut des applications pour les services ...

1
genki

Avez-vous essayé d'installer/exécuter votre service en tant qu'utilisateur nommé différent.

Si cela fonctionne, vous pouvez être sûr que vous avez un problème d'autorisations pour lequel votre compte système local n'a pas l'autorisation d'écrire dans le répertoire/fichier. 

1
Eoin Campbell

Après avoir créé un projet d'installation pour mon service et l'avoir installé plusieurs fois, j'ai finalement réalisé que je n'avais pas inclus le fichier NLog.config parmi les fichiers à installer. Maintenant qu’il est inclus à côté de l’exécutable, cela fonctionne parfaitement. 

Pour ce que cela vaut, le fichier NLog.config peut être ajouté manuellement après coup, mais le service devra peut-être être arrêté et redémarré.

0
jwatts1980

C'est peut-être que votre service s'exécute dans un autre contexte utilisateur et également en raison de restrictions Windows. J'ai eu le même problème et l'ai résolu en me connectant dans le dossier suivant:

Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)

Peut-être que cela vous aidera.

0
Aykut Çevik

J'ai eu un problème très étroitement lié. Mon NLOG ressemblait à ceci:

<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.nlog-project.org/schemas/NLog.xsd NLog.xsd"
  autoReload="true"
  throwExceptions="false"
  internalLogLevel="Off"
  internalLogFile="c:\temp\nlog-internal.log">

<targets>
<!-- Write events to a file with the date in the filename -->
<target xsi:type="File"
  name="File"
  fileName="${basedir}/logs/${shortdate}.log"
  layout="${longdate} ${uppercase:${level}} ${message}" />
</targets>

<rules>
<!-- Exception levels: Fatal, Error, Warn, Info, Debug, Trace -->
<logger name="*"
  minlevel="Debug"
  writeTo="File" />
</rules>

Tout était lié à la permission. Premièrement, là où j'ai installé le service, je devais m'assurer que le compte LOCAL SERVICE était autorisé à lire/écrire dans le dossier Logs .

Deuxièmement, le fichier internalLogFile, bien qu’il n’ait pas été écrit, semble tenter d’y accéder malgré tout - c’est pourquoi j’ai résolu mon problème en veillant à ce que LOCAL SERVICE ait l’autorisation de lire/écrire dans ** c:\temp ** 

0
Simon Miller