sbt-native-packager icon indicating copy to clipboard operation
sbt-native-packager copied to clipboard

startRunlevels not set

Open brstorrie opened this issue 8 years ago • 5 comments
trafficstars

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!

brstorrie avatar Mar 20 '17 20:03 brstorrie

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.

muuki88 avatar Mar 30 '17 06:03 muuki88

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
}

brstorrie avatar Apr 04 '17 21:04 brstorrie

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.

muuki88 avatar Apr 06 '17 07:04 muuki88

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.

brstorrie avatar Apr 10 '17 20:04 brstorrie

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")
   )

}

muuki88 avatar Apr 11 '17 07:04 muuki88