開発メモその71 NLogでLoggerの読み込みに失敗する

Problem

NLogはシンプルで使いやすいです。
個人的にはlog4netよりもシンプルで使いやすくて好きです。

そんなNLogで、複数のLoggerを準備している際に問題が起きました。
下記のようなNLog.configです。

<?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="ABC" xsi:type="File" fileName="file.txt" />
    <target name="DEF_" xsi:type="File" fileName="file.txt" />
    <target name="GHI" xsi:type="File" fileName="file.txt" />
  </targets>

  <rules>
    <logger name="ABCLogger" minlevel="Info" writeTo="ABC" />
    <logger name="DEFLogger" minlevel="Trace" writeTo="DEF" />
    <logger name="GHILogger" minlevel="Trace" writeTo="GHI" />
  </rules>
</nlog>

<?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>

<rules>

</rules>

</nlog>

このファイルをアプリと一緒に読み込み、LogManager.GetLogger("GHILogger");と実行してもログを書き出すことができません。
しかもエラーも発生しません。

Solution

ポイントは、targets内の、targetセクションにおいて、rules内のloggerセクションのwriteTo属性と対応付けすることが出来ないtargetが存在することになります。
つまり、DEF_がそれです。
このため、NLogの内部では処理がおかしくなっているのか、ABCLoggerは読み込めますが、次のDEFLoggerは対応付くDEFが存在しないため読み込めません。
さらに不味いのは、この状態だと後続のGHILoggerも読めません。
途中で対応付けに失敗すると、それ以降の対応付けに失敗あるいは対応付けそのものを中止してしまうのでしょう。

対応は簡単です。

targetのname属性またはloggerのwriteTo属性を正しく対応付けるように修正するだけです。
この場合は、2番目のtargetのname属性をDEFに修正することで正しく動きます。

仕事で、ログが出力されなくて悩みましたが、一見無関係に見える、使っていないLoggerが影響するとは思いませんでした。

Takuya Takeuchi By Takuya Takeuchi | 2017年6月20日 | Logging, NLog | No Comments |

.NETでLinuxと遊んでみる Visual Studio Code編第5回

Introduction

前回は、System.IO.FileStreamを使ってファイルのアクセス権限を確認してみました。

A certain engineer "COMPLEX"

.NETでLinuxと遊んでみる Visual Studio Code編第4回

https://taktak.jp/2017/05/27/net%e3%81%a7linux%e3%81%a8%e9%81%8a%e3%82%93%e3%81%a7%e3%81%bf%e3%82%8b-visual-studio-code%e7%b7%a8-%e7%ac%ac4%e5%9b%9e/

Introduction前回は、System.IO.DirectoryInfoを使って、ファイルの一覧を列挙してみました。今回はファイルへのアクセス可否についてです。May I open this file?Windo...

今回は少し高度なファイルへのアクセス可否についてです。

P/Invoke

ファイルに実際にアクセスしてみて、アクセスできるかどうかを試すって、結構良くないと思います。
かといって、Windowsの.NET Frameworkにアクセスできるかどうかを試すAPIは無かったはずです。

ですが、Linuxのシステムコールを使えば、それが実現可能です。
システムコールの呼び出しは当然P/Invokeで実現します。

Linuxのシステムコールで、ファイルに対して、読み込みができるか、書き込みが出来るか、実行できるか、という状態を調べるには、accessを呼び出します。

linuxjm.osdn.jp

Man page of ACCESS

https://linuxjm.osdn.jp/html/LDP_man-pages/man2/access.2.html

大抵のシステムコールはlibcに定義されています。
実際に、libcに定義されている関数の一覧からaccessを探してみます。
そのために、nmコマンドに-Dオプションを渡します。

$ nm -D /usr/lib64/lib.so.6 | grep access
00000000000e8ce0 W access
00000000000e8d10 W eaccess
00000000000e8d10 W euidaccess
00000000000e8e30 T faccessat

$ nm -D /usr/lib64/lib.so.6 | grep access

00000000000e8ce0 W access

00000000000e8d10 W eaccess

00000000000e8d10 W euidaccess

00000000000e8e30 T faccessat

これでlibcにaccessが定義されていることがわかりました。

次にaccessの使い方です。
定義は下記です。

int access(const char *pathname, int mode);

1	int access(const char *pathname, int mode);

第一引数はファイルパスです。
第二引数は調べるモードを表します。

値	意味
F_OK	存在するか
R_OK	読み込み可能か
W_OK	書き込み可能か
X_OK	実行可能か

第二引数のモードを組み合わせることで、アクセス可否をチェックします。
指定したモードを満たせば、0を返します。
満たさない場合は-1を返します。

Try

今回は、/etc/passwdを調べてみます。

$ ls -la /etc/passwd
-rw-r--r--. 1 root root 2336  4月 20 23:58 /etc/passwd

1 2	$ ls -la /etc/passwd -rw-r--r--. 1 root root 2336 4月 20 23:58 /etc/passwd

root以外は、読み込みしかできません。

では、これをコードで調べてみます。

using System;
using System.IO;
using System.Runtime.InteropServices;
using System.Text;

namespace ConsoleApplication
{
    public class Program
    {

        internal enum Mode : int
        {
            F_OK = 0,
            X_OK = 1,
            W_OK = 2,
            R_OK = 4
        }

        [DllImport("libc")]
        internal static extern int access(string path, Mode mode);

        public static void Main(string[] args)
        {
            if (args.Length != 1)
            {
                Console.WriteLine("Must specify full path!!");
                return;
            }

            var path = args[0];
            if (access(path, Mode.F_OK) != 0)
            {
                Console.WriteLine("Specified path does not exist!!");
                return;
            }

            Console.WriteLine(access(path, Mode.R_OK) == 0 ? "Can read" : "Can not read");
            Console.WriteLine(access(path, Mode.W_OK) == 0 ? "Can write" : "Can not write");
            Console.WriteLine(access(path, Mode.X_OK) == 0 ? "Can exec" : "Can not exec");
        }
    }

}

using System;

using System.IO;

using System.Runtime.InteropServices;

using System.Text;

namespace ConsoleApplication

{

public class Program

{

internal enum Mode : int

{

F_OK = 0,

X_OK = 1,

W_OK = 2,

R_OK = 4

}

[DllImport("libc")]

internal static extern int access(string path, Mode mode);

public static void Main(string[] args)

{

if (args.Length != 1)

{

Console.WriteLine("Must specify full path!!");

return;

}

var path = args[0];

if (access(path, Mode.F_OK) != 0)

{

Console.WriteLine("Specified path does not exist!!");

return;

}

Console.WriteLine(access(path, Mode.R_OK) == 0 ? "Can read" : "Can not read");

Console.WriteLine(access(path, Mode.W_OK) == 0 ? "Can write" : "Can not write");

Console.WriteLine(access(path, Mode.X_OK) == 0 ? "Can exec" : "Can not exec");

}

引数で指定したファイルの読み込み、書き込み、実行の可否を調べます。

前回同様、まずは、一般ユーザで確認します。
whichでdotnetコマンドの場所を調べているのは、rootユーザでdotnetまでのパスが通っていなかったので、実施しているだけです。
パスが通っているなら不要です。
引数のファイルパスはdotnet runの直後に追記することで指定できます。

# dotnetコマンドの場所を調べます
$ which dotnet
/opt/rh/rh-dotnetcore11/root/usr/bin/dotnet

$ /opt/rh/rh-dotnetcore11/root/usr/bin/dotnet run /etc/passwd
Can read
Can not write
Can not exec

# dotnetコマンドの場所を調べます

$ which dotnet

/opt/rh/rh-dotnetcore11/root/usr/bin/dotnet

$ /opt/rh/rh-dotnetcore11/root/usr/bin/dotnet run /etc/passwd

Can read

Can not write

Can not exec

読み込みしかできないようです。
ls -laで調べたとおりです。

続いて、rootで確認します。

$ sudo /opt/rh/rh-dotnetcore11/root/usr/bin/dotnet run /etc/passwd
Can read
Can write
Can not exec

$ sudo /opt/rh/rh-dotnetcore11/root/usr/bin/dotnet run /etc/passwd

Can read

Can write

Can not exec

読み書きができて、実行できないことが確認できました。
これも、ls -laで調べたとおりです。

では、存在しないファイルを指定してみます。

$ /opt/rh/rh-dotnetcore11/root/usr/bin/dotnet run /etc/passwd2
Specified path does not exist!!

1 2	$ /opt/rh/rh-dotnetcore11/root/usr/bin/dotnet run /etc/passwd2 Specified path does not exist!!

きちんと存在しないことを確認してくれます。

フォルダも調べることが出来ます。

$ ls -lad /etc
drwxr-xr-x. 141 root root 8192  5月 27 16:15 /etc
$ /opt/rh/rh-dotnetcore11/root/usr/bin/dotnet run /etc
Can read
Can not write
Can exec
$ sudo /opt/rh/rh-dotnetcore11/root/usr/bin/dotnet run /etc
Can read
Can write
Can exec

$ ls -lad /etc

drwxr-xr-x. 141 root root 8192 5月 27 16:15 /etc

$ /opt/rh/rh-dotnetcore11/root/usr/bin/dotnet run /etc

Can read

Can not write

Can exec

$ sudo /opt/rh/rh-dotnetcore11/root/usr/bin/dotnet run /etc

Can read

Can write

Can exec

Conclusion

Windows同様、P/Invokeが利用可能であることを確認できました。

Takuya Takeuchi By Takuya Takeuchi | 2017年5月27日 | .NET, .NET Core, .NET Framework, .NETで○○○を試してみる, .NETでLinuxと遊んでみる, C#, Linux, Microsoft, Red Hat Enterprise Linux | No Comments |

.NETでLinuxと遊んでみる Visual Studio Code編第4回

Introduction

前回は、System.IO.DirectoryInfoを使って、ファイルの一覧を列挙してみました。

A certain engineer "COMPLEX"

.NETでLinuxと遊んでみる Visual Studio Code編第3回

https://taktak.jp/2017/05/26/net%E3%81%A7linux%E3%81%A8%E9%81%8A%E3%82%93%E3%81%A7%E3%81%BF%E3%82%8B-visual-studio-code%E7%B7%A8-%E7%AC%AC3%E5%9B%9E/

Introduction前回は、デバッグ時に引数を指定して実行してみました。今回はファイルパスを使ったAPIのメモです。System.IO.DirectoryInfo相対パス扱いなの?前回、デバッ...

今回はファイルへのアクセス可否についてです。

May I open this file?

Windows上のC#なら、ファイルに書き込みできるかどうか等は、実際にファイルへのストリームを作成してみたりします。

private bool CanRead(string path)
{
    FileStream stream = null;
 
    try
    {
        stream = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.None);
    }
    catch
    {
        return false;
    }
    finally
    {
        stream?.Dispose();
    }
 
    return true;
}

private bool CanRead(string path)

{

FileStream stream = null;

try

{

stream = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.None);

}

catch

{

return false;

}

finally

{

stream?.Dispose();

}

return true;

}

では、Linuxでこれを実施するとどうなるでしょう?
ありがちなのは、所有者がrootになっていて、root以外が読み込みも出来ないパターンです。
例えば、/etc/sudo.confがそうです。

$ ls -la /etc/sudo.conf
-rw-r-----. 1 root root 1786 11月 24  2016 /etc/sudo.conf
$ cat /etc/sudo.conf
cat: sudo.conf: 許可がありません

$ ls -la /etc/sudo.conf

-rw-r-----. 1 root root 1786 11月 24 2016 /etc/sudo.conf

$ cat /etc/sudo.conf

cat: sudo.conf: 許可がありません

なので、こんなソースを用意してみました。

using System;
using System.IO;

namespace ConsoleApplication
{
    public class Program
    {
        public static void Main(string[] args)
        {
            if (args.Length != 1)
            {
                Console.WriteLine("Must specify full path!!");
                return;
            }

            var path = args[0];
            if (!File.Exists(path))
            {
                Console.WriteLine("Specified path does not exist!!");
                return;
            }

            FileStream stream = null;

            try
            {
                stream = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.None);
                Console.WriteLine($"'{path}' can be opened!!");
            }
            catch (Exception ex)
            {
                Console.WriteLine($"Can not open file. Reason: {ex.Message}!!");
            }
            finally
            {
                stream?.Dispose();
            }
        }
    }
}

using System;

using System.IO;

namespace ConsoleApplication

{

public class Program

{

public static void Main(string[] args)

{

if (args.Length != 1)

{

Console.WriteLine("Must specify full path!!");

return;

}

var path = args[0];

if (!File.Exists(path))

{

Console.WriteLine("Specified path does not exist!!");

return;

}

FileStream stream = null;

try

{

stream = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.None);

Console.WriteLine($"'{path}' can be opened!!");

}

catch (Exception ex)

{

Console.WriteLine($"Can not open file. Reason: {ex.Message}!!");

}

finally

{

stream?.Dispose();

}

引数で指定したファイルを開くことが出来れば、'' can be opened!!と表示されます。
ファイルを開こうとして、例外を投げれば、開けなかった理由が表示される、というシンプルなテストです。

ソースを記述したら、プロジェクトフォルダで

$ dotnet restore
$ dotnet build

1 2	$ dotnet restore $ dotnet build

を実行します。
これでビルドが成功するはずです。

まずは、一般ユーザで確認します。
whichでdotnetコマンドの場所を調べているのは、rootユーザでdotnetまでのパスが通っていなかったので、実施しているだけです。
パスが通っているなら不要です。
引数のファイルパスはdotnet runの直後に追記することで指定できます。

# dotnetコマンドの場所を調べます
$ which dotnet
/opt/rh/rh-dotnetcore11/root/usr/bin/dotnet

$ /opt/rh/rh-dotnetcore11/root/usr/bin/dotnet run /etc/sudo.conf
Can not open file. Reason: Access to the path '/etc/sudo.conf' is denied.!!

# dotnetコマンドの場所を調べます

$ which dotnet

/opt/rh/rh-dotnetcore11/root/usr/bin/dotnet

$ /opt/rh/rh-dotnetcore11/root/usr/bin/dotnet run /etc/sudo.conf

Can not open file. Reason: Access to the path '/etc/sudo.conf' is denied.!!

アクセスが拒否されています。

続いて、rootで確認します。

$ sudo /opt/rh/rh-dotnetcore11/root/usr/bin/dotnet run /etc/sudo.conf
'/etc/sudo.conf' can be opened!!

1 2	$ sudo /opt/rh/rh-dotnetcore11/root/usr/bin/dotnet run /etc/sudo.conf '/etc/sudo.conf' can be opened!!

無事にアクセスできました。

Conclusion

基本的なアクセス権も.NET Coreで対処できそうです。
次回は、もう少し高度な方法で読み書きできるかを調べてみたいと思います。

Takuya Takeuchi By Takuya Takeuchi | 2017年5月27日 | .NET, .NET Core, C#, Linux, Microsoft, Red Hat Enterprise Linux | No Comments |

.NETでLinuxと遊んでみる Visual Studio Code編第3回

Introduction

前回は、デバッグ時に引数を指定して実行してみました。

A certain engineer "COMPLEX"

.NETでLinuxと遊んでみる Visual Studio Code編第2回

https://taktak.jp/2017/05/25/net%E3%81%A7linux%E3%81%A8%E9%81%8A%E3%82%93%E3%81%A7%E3%81%BF%E3%82%8B-visual-studio-code%E7%B7%A8-%E7%AC%AC2%E5%9B%9E/

Introduction前回は、GUIからgitによるコミットを実行しました。今回はDebug時の引数指定のメモです。Tryデバッグ時の引数を指定してみます。Visula Studio使っているな...

今回はファイルパスを使ったAPIのメモです。

System.IO.DirectoryInfo

相対パス扱いなの?

前回、デバッグ引数として、~/を指定しました。
Linuxにおいてこのパスは、実行ユーザのホームディレクトリを示します。
(~も同様。)

これを使って、下記のコードを実行します。

using System;

namespace ConsoleApplication
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var path = args[0];
            Console.WriteLine($"Path is '{path}'");
            foreach(var f in new System.IO.DirectoryInfo(path).GetFiles())
                Console.WriteLine($"{f.Name}");
        }
    }
}

using System;

namespace ConsoleApplication

{

public class Program

{

public static void Main(string[] args)

{

var path = args[0];

Console.WriteLine($"Path is '{path}'");

foreach(var f in new System.IO.DirectoryInfo(path).GetFiles())

Console.WriteLine($"{f.Name}");

}

よくある、指定したパスの配下のファイルを列挙するプログラムです。

docs.microsoft.com

GetFiles Method

https://docs.microsoft.com/en-us/dotnet/api/system.io.directoryinfo.getfiles?view=netcore-1.1

これを実行すると下記の例外を投げます。

Unhandled Exception: System.IO.DirectoryNotFoundException: Could not find a part of the path '/home/XXXXXX/git/Demo/DotNetCoreLinux3/~/'.
   at System.IO.UnixFileSystem.FileSystemEnumerable`1.OpenDirectory(String fullPath)
   at System.IO.UnixFileSystem.FileSystemEnumerable`1.Enumerate()
   at System.IO.UnixFileSystem.FileSystemEnumerable`1..ctor(String userPath, String searchPattern, SearchOption searchOption, SearchTarget searchTarget, Func`3 translateResult)
   at System.IO.UnixFileSystem.EnumerateFileSystemInfos(String fullPath, String searchPattern, SearchOption searchOption, SearchTarget searchTarget)
   at System.IO.DirectoryInfo.InternalGetFiles(String searchPattern, SearchOption searchOption)
   at System.IO.DirectoryInfo.GetFiles()
   at ConsoleApplication.Program.Main(String[] args) in /home/XXXXXX/git/Demo/DotNetCoreLinux3/Program.cs:line 11

Unhandled Exception: System.IO.DirectoryNotFoundException: Could not find a part of the path '/home/XXXXXX/git/Demo/DotNetCoreLinux3/~/'.

at System.IO.UnixFileSystem.FileSystemEnumerable`1.OpenDirectory(String fullPath)

at System.IO.UnixFileSystem.FileSystemEnumerable`1.Enumerate()

at System.IO.UnixFileSystem.FileSystemEnumerable`1..ctor(String userPath, String searchPattern, SearchOption searchOption, SearchTarget searchTarget, Func`3 translateResult)

at System.IO.UnixFileSystem.EnumerateFileSystemInfos(String fullPath, String searchPattern, SearchOption searchOption, SearchTarget searchTarget)

at System.IO.DirectoryInfo.InternalGetFiles(String searchPattern, SearchOption searchOption)

at System.IO.DirectoryInfo.GetFiles()

at ConsoleApplication.Program.Main(String[] args) in /home/XXXXXX/git/Demo/DotNetCoreLinux3/Program.cs:line 11

Could not find a part of the path '/home/XXXXXX/git/Demo/DotNetCoreLinux3/~/'という記述から、指定したパスは、カレントディレクトリからの相対パス扱いになってしまいました。
なので、System.IO.Path.GetFullPathメソッドで絶対パスに変換してみます。

docs.microsoft.com

GetFullPath Method

https://docs.microsoft.com/en-us/dotnet/api/system.io.path.getfullpath?view=netcore-1.1#System_IO_Path_GetFullPath_System_String_

using System;

namespace ConsoleApplication
{
    public class Program
    {
        public static void Main(string[] args)
        {
            Console.WriteLine($"Argument is '{args[0]}'");

            var path = System.IO.Path.GetFullPath(args[0]);
            Console.WriteLine($"Path is '{path}'");

            foreach(var f in new System.IO.DirectoryInfo(path).GetFiles())
                Console.WriteLine($"{f.Name}");
        }
    }
}

using System;

namespace ConsoleApplication

{

public class Program

{

public static void Main(string[] args)

{

Console.WriteLine($"Argument is '{args[0]}'");

var path = System.IO.Path.GetFullPath(args[0]);

Console.WriteLine($"Path is '{path}'");

foreach(var f in new System.IO.DirectoryInfo(path).GetFiles())

Console.WriteLine($"{f.Name}");

}

変わらず同じ例外が出力されます。
デバッグコンソールの出力は下記のようになります。

Argument is '~'
Path is '/home/XXXXXX/git/Demo/DotNetCoreLinux3/~'

1 2	Argument is '~' Path is '/home/XXXXXX/git/Demo/DotNetCoreLinux3/~'

なので、~はダメな模様。

ルートから指定してみる

Windowsでも、パス指定の際の基準はカレントディレクトリになりました。
でも、フルパスを指定したなら、それはフルパスとして解釈されます。
間違っても、<カレントディレクトリ>\<フルパス>みたいな解釈はされません。

Linuxでもそうなるでしょうか?
Linuxにおけるルートは/になります。

次は、デバッグ引数に/を指定して、実行してみます。
無事に最後まで実行できています。
また、/はGetFullPathでも/として認識されています。

きちんとルートディレクトリの内容と比較してみます。
同じ内容であることがわかります。

Conclusion

少しずつ基本的なAPIを使えるようになってきました。
Windows/Mac/Linuxでの挙動の違いを比較してみたいですね。

Takuya Takeuchi By Takuya Takeuchi | 2017年5月26日 | .NET, .NET Core, C#, Linux, Microsoft, Red Hat Enterprise Linux, Visual Studio Code | No Comments |

.NETでLinuxと遊んでみる Visual Studio Code編第2回

Introduction

前回は、GUIからgitによるコミットを実行しました。

A certain engineer "COMPLEX"

.NETでLinuxと遊んでみる Visual Studio Code編第1.5回

https://taktak.jp/2017/05/25/net%E3%81%A7linux%E3%81%A8%E9%81%8A%E3%82%93%E3%81%A7%E3%81%BF%E3%82%8B-visual-studio-code%E7%B7%A8-%E7%AC%AC1-5%E5%9B%9E/

Introduction前回は、CUI、GUIから.NET Coreのプロジェクトを実行、デバッグしました。今回はちょっと脇道で、バージョン管理システムとしてgitをVisual Studio Codeか...

今回はDebug時の引数指定のメモです。

Try

デバッグ時の引数を指定してみます。
Visula Studio使っているなら、プロジェクトのプロパティ見て、引数を、ってのがすぐ思い浮かべますが、プロジェクトファイルが存在しない(.NET Core 1.1の場合)ので、ちょっと構えてしまいます。

Debugの手順については、きちんと下記の公式ページのLaunch.json attributesに明記されています。

code.visualstudio.com

Debugging in Visual Studio Code

https://code.visualstudio.com/docs/editor/debugging#_launchjson-attributes

One of the great things in Visual Studio Code is debugging support. Set breakpoints, step-in, inspect variables and more.

このlaunch.jsonが肝になります。
ちょっと上のページは文字だけでわかりにくいので画像をつけて。

まずdotnet newでプロジェクト作成後のフォルダを開いた状態です。

Program.csの内容は

using System;

namespace ConsoleApplication
{
    public class Program
    {
        public static void Main(string[] args)
        {
            Console.WriteLine(args[0]);
        }
    }
}

using System;

namespace ConsoleApplication

{

public class Program

{

public static void Main(string[] args)

{

Console.WriteLine(args[0]);

}

に変更します。
また、Console.WriteLineの行とその次の行にブレークポイントを貼っておきます。

左側のデバッグアイコンをクリックします。

デバッグペインが出現するので、上部の歯車アイコンをクリックします。

.NET Coreを選択します。

launch.jsonが作成されて表示されます。
name:が.NET Core Launch (console)になっているセクションを

"program": ${workspaceRoot}/bin/Debug/
/<project-name.dll>
- "program": ${workspaceRoot}/bin/Debug/netcoreapp1.1/DotNetCoreLinux2.dll に変更
"args: []"
- "args: ["~/"]"

に変更して、保存します。