Linux run app as service

How to run a .NET Core console app as a service using Systemd on Linux (RHEL)

Niels Swimberghe — 1/31/2020 — .NET

This article walks us through running a .NET Core console application on systemd. After running a simple console app as a service, we’ll upgrade to the worker template which is designed for long running services/ daemons . Lastly, we’ll add the systemd package for increased integration with systemd.

To learn how to run ASP.NET Core services (web stuff) on Linux, check out «How to run ASP.NET Core as a service on Linux without reverse proxy, no NGINX or Apache».

• Red Hat Enterprise Linux (or a compatible Unix based OS)
• .NET Core 3.1 installed (Get started instructions from Red Hat)
• Sudo privileges

This walkthrough should work for most .NET Core supported Linux distributions, not just RHEL.

.NET Core console application #

Let’s start by making a new console application using the dotnet CLI:

Verify that the console app works by running ` dotnet run `. The output should be «Hello World!».
If the application works, we can publish it somewhere logical such as ‘/srv/HelloWorld’:

The published result contains an executable called ‘HelloWorld’ which will run the application. Let’s verify we can also run the published application:

To run services on Linux, Systemd uses ‘ service unit configuration ‘ files to configure services.
Let’s create the file ‘HelloWorld.service’ inside our project so we can store it in source control along with our code. Add the following content to the file:

Make sure to update the ‘User’ to your username. Refer to the comments in the file for a basic explanation. For more in depth information, read the freedesktop manual page or the Red Hat documentation.

Systemd expects all configuration files to be put under ‘/etc/systemd/system/’. Copy the service configuration file to ‘/etc/systemd/system/HelloWorld.service‘. Then tell systemd to reload the configuration files, and start the service.

Using the ` systemctl status ` command we can view the status of the service:

In addition to the status command, we can use the ‘journalctl’ command to read everything our service is printing to the console. Using the unit-flag (-u), we can filter down to our HelloWorld service.

The console app only logs «Hello world!» to the console and then exits. When querying the status, systemd reports the service is inactive (dead). That’s because the console app starts, runs, and immediately exits. That’s not very useful, so let’s add some code that will let the app run until told to stop. Update Program.cs with the following content:

Let’s publish the app again:

Now we have a minimal application that is continuously running until told to stop.
If the application stops due to a crash, systemd will not automatically restart the service unless we configure that. Add the ‘Restart’ & ‘RestartSec’ options to HelloWorld.service:

Copy the service file, reload, and restart the service:

Now the service will automatically restart in case of a crash. But when the OS reboots, the application will not automatically start. To enable automatic startup of the service on boot, run the following command:

This console app works fine, but Microsoft has provided the worker template which is a more robust solution for long running services/daemons. Let’s upgrade to using the worker template next.

.NET Core worker template #

Let’s create a new empty directory and create the worker using the dotnet CLI:

Verify the worker is functional using the command ` dotnet run `.
If the application works, publish it somewhere logical such as ‘/srv/Worker’:

Let’s verify we can also run the published application:

Create a s ervice unit configuration file called «Worker.service» inside our project:

Copy the service configuration file to ‘ /etc/systemd/system/Worker.service ‘ and tell systemd to reload the configuration files:

Using ‘journalctl’, we can verify that the application is contentiously running successfully. The following ‘journalctl’ command will follow the output of the application. Use Ctrl-C to exit the command.

The .NET Core worker now runs as a systemd service, but the integration between .NET Core and systemd can bi improved on by installing the systemd-integration.

Adding .NET Core Systemd integration #

Microsoft recently added a package to better integrate with systemd. The .NET Core application will notify systemd when it’s ready and when it’s stopping. Additionally, systemd will now understand the different log levels when the .NET Core application logs to output.

Using the dotnet CLI, add the ‘Microsoft.Extensions.Hosting.Systemd’ ( nuget ) package:

Next, we’ll need to add one line to the ‘Program.cs’, ` .UseSystemd() `:

Lastly, we need to update our service unit configuration file to specify ‘type=Notify’:

Let’s publish, reload, and restart the service:

With the Systemd integration in place, we can now use the priority-flag (-p) on ‘journalctl’ to filter the output according to the log levels below:

LogLevel	Syslog level	systemd name
Trace/Debug	7	debug
Information	6	info
Warning	4	warning
Error	3	err
Critical	2	crit

For example, the following command will only print output with log level 4 and below:

We won’t see much because there’s nothing being logged as a warning, error, or critical.
Update the ‘Worker.cs’ file to include ‘LogWarning’, ‘LogError’, ‘LogCritical’ and republish:

Republish and restart the service:

When we run the same ‘journalctl’ command, we can now see the warning output as bold white text, the error and critical output as red bold text.

The ‘UseSystemd’ function will not do anything when run outside of a systemd service.
The implementation checks if the OS is a Unix system and whether the parent process is systemd.
If not, the systemd integration is skipped.

Summary #

.NET Core has good support for running services on Linux. Using the worker template, we can create a long running service/daemon that integrates well with systemd. Using the systemd hosting integration, systemd is notified when the .NET Core application is ready & also understand the different log levels in .NET.

Источник

How can I make an executable run as a service?

On Ubuntu 18.04, I can start or stop some service by

I can list some services by

The output matches the files under /etc/init.d/ .

I heard there are several ways of managing services: system V init, systemd, upstart, . Which one am I using? man service shows it is system V init. But I heard that Linux replaces init with systemd. Shall I use systemd instead of init on Ubuntu?

How can I make an arbitrary executable file (either ELF or shell script) become a service?

Do I need to explicitly daemonize the executable by setsid , like https://stackoverflow.com/a/19235243/156458?

Does any of the post below apply to me?

2 Answers 2

I heard there are several ways of managing services: system V init, systemd, upstart, . Which one am I using?

You’re using systemd, that’s the init that’s shipped on Ubuntu 18.04. (Also on Ubuntu 16.04, on Fedora, on openSUSE, on Arch Linux, on RHEL 7, on CentOS 7, on CoreOS, and it’s also the default on Debian 9.)

One good way to confirm that you’re running systemd is to run the command systemctl . If it’s available and it produces output when run, then you’re running systemd.

On Ubuntu 18.04, I can start or stop some service by

I can list some services by

Please note that the service command shipped in some systemd distros is there mostly for backward compatibility. You should try to manage services using systemctl instead.

And you can find status of all units with a simple

The output matches the files under /etc/init.d/ .

That’s not necessarily the case with systemctl , since systemd native units are stored in /etc/systemd/system/ and /usr/lib/systemd/system/ .

systemd does include compatibility with old SysV init scripts (through systemd-sysv-generator, which creates a systemd native service unit calling the commands from the init script), so if you have init scripts under /etc/init.d/ , they’ll most likely show up in systemd as well.

Shall I use systemd instead of init on Ubuntu?

This question is unclear.

The term init generally refers to the first process run when the system boots, the process run with PID 1. systemd runs with PID 1, so by definition systemd is an init (and so was upstart before it, and SysV init as well.)

If you’re asking «should I use systemd instead of SysV init?», well then you’re already using systemd instead of SysV init, since you’re on Ubuntu 18.04. (And, as pointed out above, most distributions you’d pick these days would most likely include systemd as their init.)

Now, you could be asking «should I use systemd units instead of init scripts?» and that question is more relevant, since arguably you have a choice here where both options will work.

My recommendation here is that you should manage services using systemd units, which is the native mode of operation. Creating an init script simply adds a layer of indirection (since the generator will just create a systemd unit for you anyways.) Furthermore, writing systemd units is simpler than writing init scripts, since you don’t have to worry about properly daemonizing and scrubbing the environment before execution, since systemd does all that for you.

How can I make an arbitrary executable file (either ELF or shell script) become a service?

See the examples on the man page. The simplest example shows how easy it can be to create a service unit:

Store this unit under /etc/systemd/system/foo.service , then reload systemd to read this unit file with:

Start the service with:

And enable it during startup with:

You can check the status of the service with:

Of course, systemd can do a lot more for you to manage services, so a typical systemd unit will be longer than this one (though not necessarily that much more complex.) Browse the units shipped with Ubuntu under /usr/lib/systemd/system/*.service to get a better picture of what’s typical, of what to expect.

No! Don’t run in background, don’t worry about process groups or sessions, etc. systemd takes care of all that for you. Just write your code to run in foreground and systemd will take care of the rest.

(If you have a service that runs in background, systemd can manage it, with Type=forking , but things are much easier when just running in foreground, so just do that if you’re starting a new service.)

Does any of the post below apply to me?

This one is about applications using the «Spring Boot» Java framework. Unless you’re writing Java code and using that framework, it’s not relevant. If you’re writing Java code, try instead to just run your service in foreground instead.

The question is about upstart, the answer is about SysV init scripts. While SysV init scripts will work with systemd, it’s preferable that you write systemd units directly, as mentioned above.

So, no, I’d say neither of those are relevant.

I’d recommend trying to learn more about systemd service units instead.

This site is also a great resource for that, so feel free to post more questions about it as you explore writing your own systemd units for your services.

Источник

Run Your Java App as a Service on Ubuntu

Bring your JAR file to Ubuntu as a service using this example service wrapper. See how to make it work, including automatic starts and logging tips.

Join the DZone community and get the full member experience.

Say you have a JAR file and you need to run it as a service. Additionally, you want it to start automatically if/when system restarts.

Ubuntu has a built-in mechanism to create custom services, enabling them to get started at system boot time and start/stop them as a service. In this post, I am going to share a simple and elegant way to create a service wrapper for your JAR file so you can run it as a service. Here we go.

Step 1: Create a Service

Copy/paste the following into the file /etc/systemd/system/my-webapp.service :

Step 2: Create a Bash Script to Call Your Service

Here’s the bash script that calls your JAR file: my-webapp

Don’t forget to give your script execute permission: sudo chmod u+x my-webapp

Step 3: Start the Service

Step 4: Set Up Logging

First, run: sudo journalctl —unit=my-webapp . See real-time logs by using the -f option.

If you want to trim them, use -n to view the specified number of lines of the log:

Tail the live log using the -f option:

Stop the service by using:

That’s it! Enjoy and show your support if you like it. Thanks!

Published at DZone with permission of Muhammad Sarwar . See the original article here.

Opinions expressed by DZone contributors are their own.

Источник

@Upnxtblog

Focused blog covering key technology trends

How to run Java application as service on Linux

In this post, we check out how to run Java application as service on Linux and also start automatically if and when the system restarts.

Before we move on to the article, let us understand what is systemd .It is part of Linux kernel that provides the System and Service Manager to bootstrap user space and manages user processes that include startup shell scripts like pm-utils, inetd, acpid , syslog, watchdog, cron and atd . systemd’s core components include the following:

• System and service manager for Linux operating systems.
• Systemctl to introspect and control the state of the systemd system and service manager.
• systemd-analyze package to determine system boot-up performance statistics and retrieve other state and tracing information from the system and service manager.

Image – systemd Architecture

In the next section, we can take look at how to make Java application as Linux Daemon

#1.Create a new file on /etc/systemd with your service name

sudo vi /etc/systemd/system/springbootapp.service

Modify Description, User, and ExecStart fields based on your application needs. WantedBy=multi-user.target denotes that this service will only be started when the system boots up to this target (a non-graphical multi-user environment).

Daemon definition file

Image – Daemon definition file

#2.Reload Linux Daemon

Use command systemctl daemon-reload to reload the service before we enable the newly added service

Image – Reload Daemon

#3.Enable newly added service

Enable the new service by using systemctl enable command.

Image – Enable service

#4.Start the service & check the status

Next step is to start the service by systemctl start command and you can check the status by using systemctl status command.

Start the service

Image – Start the service

#5.Stop / Disable service

As the last step, if we want to stop the service, use systemctl stop command.

Image – Stop the service

If you want to disable the service, use systemctl disable command.

Congrats! today we have learned how to Java application as Linux daemon service. If you re-look at the steps, it’s the same for any kind of application.

There are also other options like System V init script but Systemd is the preferred option as of now.

Like this post? Don’t forget to share it!

Источник