sbt-native-packager
sbt-native-packager copied to clipboard
startRunlevels not set
Building an RPM on OS X successfully, but the startRunlevels for SystemV don't seem to take. I'm using 1.2.0-M8
plugin added in plugins.sbt:
addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "1.2.0-M8")
plugin config in build.sbt:
lazy val root = (project in file(".")).
configs(Configs.all: _*).
settings(commonSettings: _*).
settings(dependencies: _*).
settings(Testing.settings: _*).
settings(DB.settings: _*).
settings(rpmSettings: _*).
enablePlugins(sbtdocker.DockerPlugin).
enablePlugins(JavaServerAppPackaging, RpmPlugin, SystemVPlugin)
lazy val rpmSettings = {
Seq(
rpmRelease := "0.1",
rpmVendor := "myorg",
packageName in Rpm := "myapp",
version in Rpm := (System.currentTimeMillis() / 1000L).toString,
rpmLicense := Some("Proprietary"),
rpmGroup := Some("myappcategory"),
defaultLinuxInstallLocation := "/opt",
packageArchitecture := "noarch",
serviceAutostart in Rpm := false,
startRunlevels in Rpm := Option("4"),
packageDescription in Rpm:= s"Custom application\n\n" +
s"Git Hash: ${
git.gitHeadCommit.value match {
case Some(gitHash) =>
s"${gitHash}"
case None => ""
}
}"
)
}
When installed (and upon examining the spec), it uses the default chkconfig settings:
Adding myapp to service management using chkconfig
[~]$ chkconfig --list myapp
myapp 0:off 1:off 2:on 3:on 4:on 5:on 6:off
I have also attempted to set the startRunlevels by appending to the root lazy val above:
...
enablePlugins(JavaServerAppPackaging, RpmPlugin, SystemVPlugin)
.settings(startRunlevels :=Option("4"))
with no success. Something I'm missing to get these startRunLevels set? I really just needed the serverAutostart feature, where I don't want to chkconfig on this service (registering is fine, but it should be off initially for my use case).
Thanks!
Thanks @brstorrie for your report.
Can you try this in your rpmSettings definition:
serviceAutostart in Linux := false,
startRunlevels in Linux := Option("4"),
I think we have still some scoping issues here.
Hi @muuki88,
Thanks for your reply. I added the settings you requested and attempted a reinstall, just to check, but it seems even the .spec is not changed regardless:
serviceAutostart in Rpm := false,
stopRunlevels in Rpm := Some("0"),
serviceAutostart in Linux := false,
startRunlevels in Linux := Option("0"),
I tried Option("0") and Option ("4"), no avail.
Interestingly, in the spec, the addService() always seems to be called upon first install, which runs chkconfig $app_name on without any sort of check:
# Scriptlet syntax: http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Syntax
# $1 == 1 is first installation and $1 == 2 is upgrade
if [ $1 -eq 1 ] ;
then
addService myapp || echo "myapp could not be registered"
fi
......
%post
# systemv support
#
# Add service for management
# $1 = service name
#
addService() {
app_name=$1
if hash update-rc.d >/dev/null 2>&1; then
echo "Adding $app_name to service management using update-rc.d"
update-rc.d $app_name defaults
elif hash chkconfig >/dev/null 2>&1; then
echo "Adding $app_name to service management using chkconfig"
chkconfig --add myapp
chkconfig $app_name on
else
echo "WARNING: Could not add $app_name to autostart: neither update-rc nor chkconfig found!"
fi
}
The startRunLevels should be set in this systemv loader script.
You can also check the linuxScripReplacements, e.g. with
sbt
$ show linuxScriptReplacements
$ show debian:linuxScriptReplacements
$ show rpm:linuxScriptReplacements
The addService should have nothing todo with this. chkconfig should read the startRunLevels from the init script.
Thanks @muuki88! It seems after some testing and using those show commands that the rpm:linuxScriptReplacements doesn't seem to be using startRunLevels or stopRunLevels defined in my lazy val.
The bottom output of show rpm:linuxScriptReplacements never changes, regardless of stop/startRunLevels in Linux or Rpm, it is always:
[info] restartService() {
[info] app_name=$1
[info] service $app_name restart
[info] }
[info] ), (start_runlevels,2 3 4 5), (stop_runlevels,0), (start_facilities,$remote_fs $syslog), (stop_facilities,$remote_fs $syslog), (term_timeout,60), (kill_timeout,30), (retries,0), (retryTimeout,60), (env_config,/etc/default/spotx-app-skittler), (daemon_log_file,spotx-app-skittler.log))
Which is the same startRunLevels I see in chkconfig. Which is great, but it doesn't seem to accept or change based on my vals :-\ Anything obvious I'm missing? I can't find anyone using these successfully in public repos.
Which is the same startRunLevels I see in chkconfig. Which is great, but it doesn't seem to accept or change based on my vals
That really shouldn't be the case. Sounds like a bug to me at this point.
The SystemVPlugin sets these levels.
Can you try one last thing. Create a small AutoPlugin to be ver sure that something isn't messed up in the order things get applied. It should looks something like this
object RunLevelPlugin extends AutoPlugin {
override def require = SystemVPlugin
override def projectSettings = Seq(
// override everything, just to be sure
serviceAutostart in Rpm := false,
stopRunlevels in Rpm := Some("0"),
serviceAutostart in Linux := false,
startRunlevels in Linux := Option("0")
)
}