/ Web Dev Zone
Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Writing a Linux Daemon in C#

DZone's Guide to

Writing a Linux Daemon in C#

With .NET Core now being available on Linux, we take a look at how to write a daemon to run .NET Core and ASP.NET Core applications. Neat, huh?

by
·
Jun. 08, 17 · Web Dev Zone ·
Free Resource

Comment (0)

Save
Tweet
{{ articles[0].views | formatCount}} Views

Download Microservices for Java Developers: A hands-on introduction to frameworks and containers. Brought to you in partnership with Red Hat.

When you want to run a .NET Core process as a daemon on Red Hat Enterprise Linux, you can create a custom systemd unit. Today, I’ll write about two examples of custom systemd units for .NET Core. One is a oneshot type for running a .NET Core console application and the other is a simple type for running an ASP.NET Core Web application.

Oneshot Type With a Console Application

Building an App

You can use dotnet run in systemd with the specifying project directory as a working directory. However, let’s build a binary file and use it for systemd. Create your project with dotnet new and edit Program.cs as follows:

using System;
using System.IO;

namespace ConsoleApplication
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var path = Path.GetTempFileName();
            File.WriteAllText(path, "Hello Temp File!");
            Console.WriteLine($"Wrote temp file: {path}");
        }
    }
}

Then publish the project with the dotnet publish command. You will see the binary files under the bin/<Configuration>/<Framework> directory.

$ dotnet publish -c Release
Publishing ConsoleApp for .NETCoreApp,Version=v1.1
Project ConsoleApp (.NETCoreApp,Version=v1.1) was previously compiled. Skipping compilation.
publish: Published to /home/tatanaka/Documents/git/tanaka-takayoshi/SystemdExample/1.1/ConsoleApp/bin/Release/netcoreapp1.1/publish
Published 1/1 projects successfully

Creating a Custom systemd

At first, create a user for running your daemon and a working directory.

$ sudo useradd -s /sbin/nologin dotnetuser
$ sudo mkdir /var/SystemdExample
$ sudo cp /home/tatanaka/Documents/git/tanaka-takayoshi/SystemdExample/1.1/ConsoleApp/bin/Release/netcoreapp1.1/publish/* /var/SystemdExample
$ sudo chown -R dotnetuser:dotnetuser /var/SystemdExample

Then create a custom systemd unit file under the /etc/systemd/system/ directory. The file name should be <unit-name>.<unit-type>. I created /etc/systemd/system/netcore-console-example.service.

[Unit]
Description=Example for .NET Core ConsoleApp with systemd
DefaultDependencies=no

[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/opt/rh/rh-dotnetcore11/root/usr/bin/dotnet ConsoleApp.dll
WorkingDirectory=/var/SystemdExample
User=dotnetuser
Group=dotnetuser


[install]

You should specify the full path of dotnet in ExecStart. In the above example, I have used the Red Hat provided .NET Core 1.1. Then you can execute the daemon with the systemctl command. You can see the console output with the systemctl status command or the journalctl command.

$ sudo systemctl start netcore-console-example.service 
$ sudo systemctl status netcore-console-example.service 
● netcore-console-example.service - Example for .NET Core ConsoleApp with systemd
   Loaded: loaded (/etc/systemd/system/netcore-console-example.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Fri 2017-02-24 00:29:16 JST; 13s ago
  Process: 18075 ExecStart=/opt/rh/rh-dotnetcore11/root/usr/bin/dotnet ConsoleApp.dll (code=exited, status=0/SUCCESS)
 Main PID: 18075 (code=exited, status=0/SUCCESS)

Feb 24 00:29:16 localhost.localdomain systemd[1]: Starting Example for .NET Core ConsoleApp with systemd...
Feb 24 00:29:16 localhost.localdomain dotnet[18075]: Wrote temp file: /tmp/tmph1ok6H.tmp
Feb 24 00:29:16 localhost.localdomain systemd[1]: Started Example for .NET Core ConsoleApp with systemd.

$ journalctl -u netcore-console-example.service -e
Feb 24 00:29:16 localhost.localdomain systemd[1]: Starting Example for .NET Core ConsoleApp with systemd...
Feb 24 00:29:16 localhost.localdomain dotnet[18075]: Wrote temp file: /tmp/tmph1ok6H.tmp
Feb 24 00:29:16 localhost.localdomain systemd[1]: Started Example for .NET Core ConsoleApp with systemd.
$ sudo cat /tmp/tmph1ok6H.tmp
Hello Temp File!

Working With PrivateTemp

In the above systemd unit, the program writes a file under temp folder. You sometimes want to write a temp file, which is secured from other users. You can use PrivateTemp by specifying this in the [Service] section.

[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/opt/rh/rh-dotnetcore11/root/usr/bin/dotnet ConsoleApp.dll
WorkingDirectory=/var/SystemdExample
User=dotnetuser
Group=dotnetuser
PrivateTemp=true

After reloading the unit file, the program can access the /tmp directory as before, but this is not an actual /tmp directory.

$ sudo systemctl daemon-reload 
$ sudo systemctl start netcore-console-example.service
$ sudo systemctl status netcore-console-example.service
● netcore-console-example.service - Example for .NET Core ConsoleApp with systemd
   Loaded: loaded (/etc/systemd/system/netcore-console-example.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Fri 2017-02-24 00:35:46 JST; 12s ago
  Process: 18415 ExecStart=/opt/rh/rh-dotnetcore11/root/usr/bin/dotnet ConsoleApp.dll (code=exited, status=0/SUCCESS)
 Main PID: 18415 (code=exited, status=0/SUCCESS)

Feb 24 00:35:46 localhost.localdomain systemd[1]: Starting Example for .NET Core ConsoleApp with systemd...
Feb 24 00:35:46 localhost.localdomain dotnet[18415]: Wrote temp file: /tmp/tmpJLWAGC.tmp
Feb 24 00:35:46 localhost.localdomain systemd[1]: Started Example for .NET Core ConsoleApp with systemd.
$ ls /tmp/tmpJLWAGC.tmp
ls: cannot access /tmp/tmpJLWAGC.tmp: No such file or directory

Building an App

Now let’s build an ASP.NET Core web application. I'll use a default template project.

$ dotnet new -t web
Created new C# project in /home/tatanaka/Documents/git/tanaka-takayoshi/SystemdExample/1.1/WebApp.
$ dotnet restore 
** snipped**
log  : Restore completed in 9721ms.
$ dotnet publish -c Release
Publishing WebApp for .NETCoreApp,Version=v1.1
** snipped **
publish: Published to /home/tatanaka/Documents/git/tanaka-takayoshi/SystemdExample/1.1/WebApp/bin/Release/netcoreapp1.1/publish
Published 1/1 projects successfully

Now it can be run with the dotnet command.

$ dotnet bin/Release/netcoreapp1.1/publish/WebApp.dll 
info: Microsoft.Extensions.DependencyInjection.DataProtectionServices[0]
      User profile is available. Using '/home/tatanaka/.aspnet/DataProtection-Keys' as key repository; keys will not be encrypted at rest.
Hosting environment: Production
Content root path: /home/tatanaka/Documents/git/tanaka-takayoshi/SystemdExample/1.1/WebApp
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.

Creating a Custom systemd

I used the same dotnetuser for this web application.

$ sudo mkdir /var/SystemdExample
$ sudo cp -R bin/Release/netcoreapp1.1/publish/* /var/SystemdWebExample
$ sudo chown -R dotnetuser:dotnetuser /var/SystemdWebExample

Then create a custom systemd unit file: /etc/systemd/system/netcore-web-example.service.

[Unit]
Description=Example for .NET Core WebApp with systemd
DefaultDependencies=no
Wants=network.target # network is required
After=network.target

[Service]
ExecStart=/opt/rh/rh-dotnetcore11/root/usr/bin/dotnet WebApp.dll
WorkingDirectory=/var/SystemdWebExample
Restart=always
RestartSec=10   # Restart service after 10 seconds if dotnet service crashes
SyslogIdentifier=dotnet-example
User=dotnetuser
Group=dotnetuser
PrivateTmp=true
Environment=ASPNETCORE_ENVIRONMENT=Production # specify environment variable for environment
Environment=ASPNETCORE_URLS=http://*:8080 # specify environement variable for listening port

[Install]
WantedBy = multi-user.target

Finally, you can run your ASP.NET Core application as a Linux daemon. Please note this application listens to port 8080 instead of ASP.NET Core default 5000 (I specified the environment variable in ASPNETCORE_URLS of the unit file).

$ systemctl start netcore-web-example.service
[tatanaka@localhost WebApp]$ systemc^C
[tatanaka@localhost WebApp]$ sudo systemctl status netcore-web-example.service
[sudo] password for tatanaka: 
● netcore-web-example.service - Example for .NET Core WebApp with systemd
   Loaded: loaded (/etc/systemd/system/netcore-web-example.service; disabled; vendor preset: disabled)
   Active: active (running) since Sat 2017-02-25 01:02:12 JST; 11s ago
 Main PID: 7041 (dotnet)
   CGroup: /system.slice/netcore-web-example.service
           └─7041 /opt/rh/rh-dotnetcore11/root/usr/bin/dotnet WebApp.dll

Feb 25 01:02:12 localhost.localdomain systemd[1]: Started Example for .NET Core WebApp with systemd.
Feb 25 01:02:12 localhost.localdomain systemd[1]: Starting Example for .NET Core WebApp with systemd...
Feb 25 01:02:12 localhost.localdomain dotnet-example[7041]: info: Microsoft.Extensions.DependencyInjection.DataProtectionServices[0]
Feb 25 01:02:12 localhost.localdomain dotnet-example[7041]: User profile is available. Using '/home/dotnetuser/.aspnet/DataProtection-Keys' as key repository; keys will not be encrypted at rest.
Feb 25 01:02:13 localhost.localdomain dotnet-example[7041]: Hosting environment: Production
Feb 25 01:02:13 localhost.localdomain dotnet-example[7041]: Content root path: /var/SystemdWebExample
Feb 25 01:02:13 localhost.localdomain dotnet-example[7041]: Now listening on: http://*:8080
Feb 25 01:02:13 localhost.localdomain dotnet-example[7041]: Application started. Press Ctrl+C to shut down.

$ journalctl -u netcore-web-example -xf
-- Logs begin at Mon 2017-02-20 11:58:31 JST. --
Feb 25 01:02:36 localhost.localdomain dotnet-example[7041]: info: Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware[2]
Feb 25 01:02:36 localhost.localdomain dotnet-example[7041]: Sending file. Request path: '/images/banner4.svg'. Physical path: '/var/SystemdWebExample/wwwroot/images/banner4.svg'
Feb 25 01:02:36 localhost.localdomain dotnet-example[7041]: info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
Feb 25 01:02:36 localhost.localdomain dotnet-example[7041]: Request finished in 0.1973ms 200 image/svg+xml
Feb 25 01:02:36 localhost.localdomain dotnet-example[7041]: info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
Feb 25 01:02:36 localhost.localdomain dotnet-example[7041]: Request starting HTTP/1.1 GET http://localhost:8080/favicon.ico
Feb 25 01:02:36 localhost.localdomain dotnet-example[7041]: info: Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware[2]
Feb 25 01:02:36 localhost.localdomain dotnet-example[7041]: Sending file. Request path: '/favicon.ico'. Physical path: '/var/SystemdWebExample/wwwroot/favicon.ico'
Feb 25 01:02:36 localhost.localdomain dotnet-example[7041]: info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
Feb 25 01:02:36 localhost.localdomain dotnet-example[7041]: Request finished in 0.5824ms 200 image/x-icon

However, this is not enough for the use of ASP.NET Core in production. You may have to set up a reverse proxy server like NGINX, firewalls, and so on. Also, if you would like to know much more about systemd, please refer our documentation.

Whether you are new to Linux or have experience, downloading this cheat sheet can assist you when encountering tasks you haven’t done lately.

Download Building Reactive Microservices in Java: Asynchronous and Event-Based Application Design. Brought to you in partnership with Red Hat. 

Like This Article? Read More From DZone

AppSettings in ASP.NET Core
Short Walks: Using AppSettings.json in ASP.NET Core
ASP.NET Core 2.0: How to Pass Data Into a Model Using DI

Free DZone Refcard

Node.js
DOWNLOAD
Topics:
asp.net core ,web dev ,daemon ,c#

Comment (0)

Save
Tweet
{{ articles[0].views | formatCount}} Views

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

Web Dev Partner Resources

App-centric Monitoring Alternatives to New Relic
Prezi on Building an Incident Log to Resolve Issues Faster
How Developers Close the User Experience Loop
DoorDash's Strategy for Monitoring Code from End to End
Top 10 JavaScript Errors and How to Avoid Them
How Instacart Improves User Experiences and Reduces Mean-Time-to-Resolve (MTTR)

Web Dev Partner Resources

App-centric Monitoring Alternatives to New Relic
Prezi on Building an Incident Log to Resolve Issues Faster
How Developers Close the User Experience Loop
DoorDash's Strategy for Monitoring Code from End to End

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.linkDescription }}

{{ parent.urlSource.name }}
by {{ parent.authors[0].realName || parent.author}}
· {{ parent.articleDate | date:'MMM. dd, yyyy' }} {{ parent.linkDate | date:'MMM. dd, yyyy' }}
· {{ parent.portal.name }} Zone