I have a service that I would like to manage through systemd - let's call it foo. I wrote unit files, and they're working just fine. So, if I run systemctl start foo, the service starts correctly, and I can see its status with systemctl status foo.

However, an external program may also start the service, and it doesn't use systemd to start the service. So, the service can be running, but since it wasn't started through systemd, systemd doesn't know about it. In this case, systemctl status foo reports that the service has failed, even though its running correctly.

Is there a way to have systemd 'inherit' or 'adopt' this service, so systemctl status foo correctly reports that the service is running, even when systemd didn't start it? With SysV, I would write a small 'status' script, so I could /etc/init.d/foo status, but that doesn't seem to fit with the systemd model.

To be clear, when the external program starts the service, the service's processes are still children of PID 1/systemd. But, systemd doesn't recognize them as part of service foo, since systemd didn't start and register them.

The specific technologies are:

• Oracle WebLogic (the service is a Managed WebLogic Instance)


• Oracle NodeManager (this is the external program that may also start the service)


• systemd 219

No. The process will be running in a different context as far as systemd is concerned.

This is, in fact, one of the reasons that Desktop Bus service activation should be avoided. Service processes directly spawned by the Desktop Bus broker are part of its service, as far as systemd is concerned.

One can move processes amongst control groups, with appropriate privileges. But this is only half of the job, and the other half, that of convincing systemd that it started a unit when it did not and rewriting the necessary parts of its internal data structures, is not provided for.

This is not only not systemd's model, it is not the model of most service management subsystems.

Far too many people's "just fine" service units for Oracle softwares actually are not, by the way, and are in House of Horror territory.

Further reading

• systemctl fails to accurately report status of daemons if they were started via mechanism other than systemctl


• configure java daemon with systemd


• https://unix.stackexchange.com/a/437461/5132


• Jonathan de Boyne Pollard (2016). Avoid Desktop Bus (D-Bus) bus activation
  . nosh. Softwares.


• Jonathan de Boyne Pollard (2015). The systemd House of Horror. Frequently Given Answers.

In short, there isn't a way to have systemd consider a service to be started unless it was started by systemd itself. One of the main points of systemd is consistency in managing services and having separate ways to start a service goes against that idea.

Now, systemd does have a provision to manage processes that are started externally, which seems to be somewhat suitable for the case you describe. That's actually a separate kind of unit, a scope unit.

Using a scope unit still requires your external system to interact with systemd, since a scope unit can only be started with a D-Bus request to systemd, in which a PID is passed which is used as the initial process in the scope. Also, when a scope unit is started, systemd still wants to create the cgroups itself (it will then move the passed PID into the created cgroups.) So, this needs support from the application creating new processes, if it wants systemd to manage those as a scope.

In short, avoid having two separate ways to start a service. If you need to use the third party service manager, use only that.

If the issue you are trying to solve is to start the service during boot up, then:

1. Check if your third party manager (in your case, Oracle NodeManager) supports configuring services during boot up. As it's managing the service, it should manage service during boot up as well.




2. If you get systemd involved, then use a simple oneshot service unit that simply requests the third party manager to start the service. This means contacting the third party manager (in your case, Oracle NodeManager) through an API or RPC of some kind, maybe through HTTP, and telling it to start the service.

If you use the systemd oneshot for startup, then name your unit appropriately (like "start-foo" or "initial-foo" or "foo-startup") to make it clear it won't stay "up", and keep RemainAfterExit= as no (the default) so checking the status on that unit will just say it's finished successfully, so there's no confusion about it reflecting the status of the service running under the third party manager.