You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm curious how your installation process exactly looks like?
From sbt-native-packager's perspective the sbt universal:package* (packageBin, packagaTarballz, etc.) tasks produce a self contained package that can be extracted and started.
there's nothing necesarrily OS-specific about a systemd service file or its location on the filesystem.
A systemloader is something OS specific. You can't (or at least it's non trivial) to use systemd on windows or macos. There are also common file locations for different systems.
If we package the systemd service file into the resulting tar/zip file, it would still do nothing as there is no proper installation mechanism. rpm and debian are configured for their OS-specific systemd paths and register the new service properly during package installation.
For all other systems there would be unnecessary files packaged. We try to only add exactly what is required to start the application.
systemd is OS specific if it should work. It's not universal like a zip file.
native-packager tries to provide only required files (notable exception are the bash and bat start script)
Having said that, if you have got good reasons to not use a package manager and want to
use systemd with universal:packageTarball there is nothing that restricts you to do so:
systemd and packageTarball
You could try to use the SystemdPlugin, which depends on the SystemloaderPlugin. However I think this is an overkill at this point as you'll need to duplicate a lot of settings that don't make much sense.
So what I would do instead: Put your service file into src/universal/systemd/myapp.service.
Your tarball will then contain the systemd/myapp.service. The nice thing is that no sbt configuration is required at all and you configure your app there. The only thing you need to take care of is that the linuxStartScriptName (by default the packageName) and the paths in your file match.
systemd is a standard - there's nothing necesarrily OS-specific about a systemd service file or its location on the filesystem.
I'm here on Arch Linux (a systemd system) installing Centos in a chroot just so I can get the java app as a systemd service.
The text was updated successfully, but these errors were encountered: