2

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
Improve this question
3

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

Improve this answer
4
  • Your comments on D-Bus activation are on point, but only when activation happens at the dbus-daemon. As your separate article points out, when systemd is involved, things work fine. So D-Bus activation with systemd (which is done with service units having Type=dbus) should be perfectly fine, and doesn't suffer from the problems you describe. Given upstart is mostly gone at this point, I think it's important to point out or clarify the context of those problems with D-Bus activation. They were more relevant in the past, before Debian/Ubuntu switched to systemd by default. – filbranden Nov 13 '18 at 19:33
  • The problem continues to be as relevant now as it was. It is a misrepresentation (another mis-application of "fine" indeed) to say that systemd has somehow cured this. If the problem weren't relevant any more, the idiosyncratic and tightly coupled communications channel between the broker and systemd would no longer be needed. It of course still is needed, with the context that broker-spawned processes run in continuing unabated to be problematic, and the fact that it is idiosyncratic and too strongly coupled continues to be the part of the problem that the Upstart people identified it as. – JdeBP Nov 13 '18 at 20:31
  • Thank you! I appreciate all the documentation - I was worried that this might be the case, but it's good to be able to point to references. "Don't ask me why, so far, all of these have involved starting Java programs. Maybe it's Oracle in general." hits too close to home, haha. – user288221 Nov 13 '18 at 20:48
  • hmm is there a little weirdness exec'ing service because it's not what you want with the old sysvinits ? you don't want a sysvinit service for a dbus-activatable service, because running service can return failure if it races with someone else, right? I guess the ol' service API wants tightening up a bit first? – sourcejedi Nov 13 '18 at 21:31
1

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.

Improve this answer
2
  • I foresee people reading this and running startNodeManager.sh as a oneshot service. They even have the likes of stackoverflow.com/questions/30640717 for bodges to pile on when it does not work. More House of Horror stuff. (-: – JdeBP Nov 13 '18 at 20:59
  • @JdeBP Rephrased that last part to make that more clear, please take a look. – filbranden Nov 14 '18 at 10:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy