Add SystemdServices package that provides Host integration for systemd. #1804

tmds · 2019-06-06T12:36:18Z

This package provides a IHostBuilder UseSystemdService method that:

changes the Console logger to ConsoleLoggerFormat.Systemd
provides SystemdServiceLifetime that triggers shutdown on SIGTERM
and which uses the systemd notify protocol to inform systemd when the service
has started, and when it is stopping.

When the extension method is used outside systemd, it noops.

Contributes to #1241.

This package provides a IHostBuilder UseSystemdService method that: - changes the Console logger to ConsoleLoggerFormat.Systemd - provides SystemdServiceLifetime that triggers shutdown on SIGTERM - and which uses the systemd notify protocol to inform systemd when the service has started, and when it is stopping. When the extension method is used outside systemd, it noops. Contributes to dotnet#1241.

tmds · 2019-06-06T12:40:42Z

The implementation mostly is a copy-paste from Tmds.Systemd adjusted to make it more DI friendly and following style of the WindowsServices package.

I'll add some tests that verify the socket peer receives the expected messages next week.

src/Hosting/SystemdServices/src/ServiceState.cs

src/Hosting/SystemdServices/src/ISystemdNotifier.cs

tmds · 2019-06-06T12:48:50Z

@glennc @davidfowl @anurse @BrennanConroy @Tratcher @gfoidl ptal

src/Hosting/SystemdServices/src/Microsoft.Extensions.Hosting.SystemdServices.csproj

src/Hosting/SystemdServices/src/ISystemdNotifier.cs

src/Hosting/SystemdServices/src/ServiceHelpers.cs

src/Hosting/SystemdServices/src/SystemdNotifier.cs

src/Hosting/SystemdServices/src/SystemdServiceHostBuilderExtensions.cs

src/Hosting/SystemdServices/src/ServiceHelpers.cs

src/Hosting/SystemdServices/Directory.Build.props

src/Hosting/SystemdServices/src/ServiceHelpers.cs

davidfowl · 2019-06-06T16:19:03Z

src/Hosting/SystemdServices/src/SystemdNotifier.cs

+        public bool IsEnabled => _socketPath != null;
+
+        /// <inheritdoc />
+        public void Notify(ServiceState state, ServiceState[] states)


Span<ServiceState>

davidfowl · 2019-06-06T16:19:48Z

src/Hosting/SystemdServices/src/SystemdNotifier.cs

+                var endPoint = new UnixDomainSocketEndPoint(_socketPath);
+                socket.Connect(endPoint);
+
+                int rv = socket.Send(data);


Async?

Errors?

I thought about async too, but it's called in a sync context, so there will be waiting anywhere.
Is socket.SendAsync(...).GetAwaiter().GetResult() a better option here?

It's currently called in a single place but this is a general purpose interface. We may need both sync and async versions.

Is socket.SendAsync(...).GetAwaiter().GetResult() a better option here?

Definitely not. I'd make this a NotifyAsync method and allow callers to decide what to do. For example, a caller could decide to fire-and-forget instead of blocking.

We can treat this as a sync API. The buffer in the kernel is far larger than what we are trying to send.

Good to know. Can you add a comment for that fact please?

We can treat this as a sync API. The buffer in the kernel is far larger than what we are trying to send.

Hrm, we generally avoid operating under assumptions like that, but I see your point. Thoughts @davidfowl ?

davidfowl · 2019-06-06T16:22:46Z

src/Hosting/SystemdServices/test/UseSystemdServiceTests.cs

+    public class UseSystemdServiceTests
+    {
+        [Fact]
+        public void DefaultsToOffOutsideOfService()


What's the strategy for testing this? Kestrel was using Docker to test the systemd activation feature https://github.com/aspnet/AspNetCore/tree/master/src/Servers/Kestrel/test/SystemdActivation, we should probably do the same here.

Some of it could be tested without systemd at all. For example the notifier could be tested by creating a socket, flowing it down (preferably via internals rather than an env-var) and reading from the other end.

But I agree, docker for a simple integration test would be good as well.

For example the notifier could be tested by creating a socket, flowing it down (preferably via internals rather than an env-var) and reading from the other end.

I plan to add such a test.

Kestrel was using Docker to test the systemd activation feature https://github.com/aspnet/AspNetCore/tree/master/src/Servers/Kestrel/test/SystemdActivation, we should probably do the same here.

Are you running these tests on regular basis?

They don't run at all, in fact, I need to file an issue to make them run again.

src/Hosting/SystemdServices/src/ISystemdNotifier.cs

analogrelay · 2019-06-06T17:01:27Z

src/Hosting/SystemdServices/src/Microsoft.Extensions.Hosting.SystemdServices.csproj

+    <TargetFramework>netstandard2.1</TargetFramework>
+    <GenerateDocumentationFile>true</GenerateDocumentationFile>
+    <PackageTags>hosting</PackageTags>
+    <IsShipping>true</IsShipping>


Should we consider this for the linux shared framework? That would make it possible to enable it by default in the worker template (assuming it does what .UseWindowsServices does and only lights up if actually hosted in systemd).

That would also mean it needs to be in source-build.

Of course, I don't know exactly what (if any?) shared framework the worker template references. Does it reference Microsoft.AspNetCore.App or Microsoft.NETCore.App? If the latter, the point is moot, it's not going in to that shared fx in this release. (cc @glennc)

We don't do this for the windows service so we shouldn't do it here either....

src/Hosting/SystemdServices/Directory.Build.props

src/Hosting/SystemdServices/src/ServiceHelpers.cs

src/Hosting/SystemdServices/src/SystemdNotifier.cs

src/Hosting/SystemdServices/src/ServiceState.cs

analogrelay · 2019-06-06T17:24:17Z

src/Hosting/SystemdServices/src/SystemdNotifier.cs

+                var endPoint = new UnixDomainSocketEndPoint(_socketPath);
+                socket.Connect(endPoint);
+
+                int rv = socket.Send(data);


Is socket.SendAsync(...).GetAwaiter().GetResult() a better option here?

Definitely not. I'd make this a NotifyAsync method and allow callers to decide what to do. For example, a caller could decide to fire-and-forget instead of blocking.

src/Hosting/SystemdServices/src/SystemdServiceLifetime.cs

analogrelay · 2019-06-06T17:25:58Z

src/Hosting/SystemdServices/test/UseSystemdServiceTests.cs

+    public class UseSystemdServiceTests
+    {
+        [Fact]
+        public void DefaultsToOffOutsideOfService()


Some of it could be tested without systemd at all. For example the notifier could be tested by creating a socket, flowing it down (preferably via internals rather than an env-var) and reading from the other end.

But I agree, docker for a simple integration test would be good as well.

src/Hosting/SystemdServices/src/ServiceHelpers.cs

src/Hosting/SystemdServices/src/SystemdServiceLifetime.cs

src/Hosting/Systemd/src/ServiceState.cs

Co-Authored-By: campersau <buchholz.bastian@googlemail.com>

jkotalik · 2019-06-07T18:35:59Z

src/Hosting/Systemd/src/SystemdHostBuilderExtensions.cs

+        /// <returns></returns>
+        public static IHostBuilder UseSystemd(this IHostBuilder hostBuilder)
+        {
+            if (SystemdHelpers.IsSystemdService ())


Suggested change

if (SystemdHelpers.IsSystemdService ())

if (SystemdHelpers.IsSystemdService())

src/Hosting/Systemd/src/SystemdLifetime.cs

davidfowl · 2019-06-10T06:33:16Z

src/Hosting/Systemd/src/SystemdNotifier.cs

+                return;
+            }
+
+            using (var socket = new Socket(AddressFamily.Unix, SocketType.Dgram, ProtocolType.Unspecified))


Is it reasonable to open and close these on demand? Is there a universe where we'd want to keep the connection open because of sending other types of messages?

This is only for occasional messaging (now: two messages per application lifetime).
The native sd_notify implementation does the same thing: create and close socket per message.
We can change the scope of the socket to the SystemdNotifier instance if it ever makes sense.

Sounds good.

tmds requested review from analogrelay, Tratcher and a team as code owners June 6, 2019 12:36

tmds commented Jun 6, 2019

View reviewed changes

src/Hosting/SystemdServices/src/ServiceState.cs Outdated Show resolved Hide resolved

tmds commented Jun 6, 2019

View reviewed changes

src/Hosting/SystemdServices/src/ISystemdNotifier.cs Outdated Show resolved Hide resolved

tmds commented Jun 6, 2019

View reviewed changes

src/Hosting/SystemdServices/src/Microsoft.Extensions.Hosting.SystemdServices.csproj Outdated Show resolved Hide resolved

gfoidl reviewed Jun 6, 2019

View reviewed changes

Eilon added the area-hosting label Jun 6, 2019

dougbu reviewed Jun 6, 2019

View reviewed changes

src/Hosting/SystemdServices/src/ServiceHelpers.cs Outdated Show resolved Hide resolved

src/Hosting/SystemdServices/Directory.Build.props Outdated Show resolved Hide resolved

davidfowl reviewed Jun 6, 2019

View reviewed changes

src/Hosting/SystemdServices/src/ServiceHelpers.cs Outdated Show resolved Hide resolved

davidfowl reviewed Jun 6, 2019

View reviewed changes

src/Hosting/SystemdServices/src/ISystemdNotifier.cs Outdated Show resolved Hide resolved

analogrelay reviewed Jun 6, 2019

View reviewed changes

Tratcher reviewed Jun 6, 2019

View reviewed changes

src/Hosting/SystemdServices/src/ServiceHelpers.cs Outdated Show resolved Hide resolved

src/Hosting/SystemdServices/src/SystemdServiceLifetime.cs Outdated Show resolved Hide resolved

tmds added 10 commits June 6, 2019 21:56

Encode in ServiceState and accept a single ServiceState in Notify

6a50284

Rename SystemdService to Systemd

ff9dbdd

Rename ServiceHelpers

f07681e

End *.cs files with a newline

d191c4e

Don't clear INVOCATION_ID envvar

75552ab

Remove ExcludeFromSourceBuild

1dce548

Document why it's fine to do a sync send

b0d5c9a

Update ref assembly

d319735

Remove ServiceState.GetData xml doc

164ebd5

Update WindowsServices ref assembly

d8c80b2

campersau reviewed Jun 7, 2019

View reviewed changes

src/Hosting/Systemd/src/ServiceState.cs Outdated Show resolved Hide resolved

Update src/Hosting/Systemd/src/ServiceState.cs

fda9cc0

Co-Authored-By: campersau <buchholz.bastian@googlemail.com>

jkotalik reviewed Jun 7, 2019

View reviewed changes

davidfowl reviewed Jun 10, 2019

View reviewed changes

analogrelay added this to the 3.0.0-preview7 milestone Jun 10, 2019

davidfowl merged commit 451fed1 into dotnet:master Jun 10, 2019

tmds mentioned this pull request Jun 11, 2019

Add tests for Systemd package #1820

Closed

ghost locked as resolved and limited conversation to collaborators May 28, 2023

	if (SystemdHelpers.IsSystemdService ())
	if (SystemdHelpers.IsSystemdService())

Add SystemdServices package that provides Host integration for systemd. #1804

Add SystemdServices package that provides Host integration for systemd. #1804

Uh oh!

Conversation

tmds commented Jun 6, 2019

Uh oh!

tmds commented Jun 6, 2019

Uh oh!

Uh oh!

Uh oh!

tmds commented Jun 6, 2019

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!