Systemd service file included in RPM scriplets

[ianjohnson]

When using the RPM and Systemd plugins the systemd service file is included in the postinstall and preuninstall scriptlets. So when you install the RPM the scriptlets generate lots of errors.

For example:

postinstall scriptlet (using /bin/sh):

[Unit]
Description=Great app
Requires=network.target

[Service]
Type=simple
WorkingDirectory=/usr/share/great_app
EnvironmentFile=/etc/default/great_app
ExecStart=/usr/share/great_app/bin/great_app
ExecReload=/bin/kill -HUP $MAINPID
Restart=always
RestartSec=60
SuccessExitStatus=
User=hb_jobs
ExecStartPre=/bin/mkdir -p /var/run/great_app
ExecStartPre=/bin/chown user:grp /var/run/great_app
ExecStartPre=/bin/chmod 755 /var/run/great_app
PermissionsStartOnly=true

[Install]
WantedBy=multi-user.target

if [ $1 -eq 1 ] ;
then
  addService job_scheduler_rest || echo "great_app could not be registered"
  startService job_scheduler_rest || echo "great_app could not be started"
fi

relocateLink() {
  if [ -n "$4" ] ;
  then
    RELOCATED_INSTALL_DIR="$4/$3"
    echo "${1/$2/$RELOCATED_INSTALL_DIR}"
  else
    echo "$1"
  fi
}

rm -rf $(relocateLink /usr/bin/great_app /usr/share/great_app great_app $RPM_INSTALL_PREFIX) && ln -s $(relocateLink /usr/share/great_app/bin/great_app /usr/share
/great_app great_app $RPM_INSTALL_PREFIX) $(relocateLink /usr/bin/great_app /usr/share/great_app great_app $RPM_INSTALL_PREFIX)
rm -rf $(relocateLink /usr/bin/dh_job_wrapper.sh /usr/share/great_app great_app $RPM_INSTALL_PREFIX) && ln -s $(relocateLink /usr/share/great_app/bin/dh_job_wrapper.sh /usr/share/great_app great_app $RPM_INSTALL_PREFIX) $(relocateLink /usr/bin/dh_job_wrapper.sh /usr/share/great_app great_app $RPM_INSTALL_PREFIX)
rm -rf $(relocateLink /etc/great_app /usr/share/great_app great_app $RPM_INSTALL_PREFIX) && ln -s $(relocateLink /usr/share/great_app/conf /usr/share/great_app great_app $RPM_INSTALL_PREFIX) $(relocateLink /etc/great_app /usr/share/great_app great_app $RPM_INSTALL_PREFIX)
rm -rf $(relocateLink /usr/share/great_app/logs /usr/share/great_app great_app $RPM_INSTALL_PREFIX) && ln -s $(relocateLink /var/log/great_app /usr/share/great_app great_app $RPM_INSTALL_PREFIX) $(relocateLink /usr/share/great_app/logs /usr/share/great_app great_app $RPM_INSTALL_PREFIX)

[muuki88]

Thanks for your report @ianjohnson

Can you give a bit more details on how your build is setup?

• What sbt-native-packager are you using
• What sbt version
• What is your build system (e.g. Ubuntu, MacOS, Windows, Debian )
• What version has your build tool (find out with e.g. rpm --version)

[ianjohnson]

sbt-native-packager: Version 1.2.0-M8

SBT: version 0.13.11

RRPM: version 4.11.3

Building on CentOS 7.2.1511

[ianjohnson]

I have also noticed that definitions for the functions {add,start,stop}Service functions are not included in the RPM scriptlets.

[muuki88]

This sounds like a regression in the latest milestone.

[zakcrawford]

I also have experienced this issue.

[zakcrawford]

It happens with an upstart script and debian package.

[muuki88]

I try to get a hold of this regression ASAP. Very likely that I introduced this in the latest milestone.

[muuki88]

@ianjohnson can you add a small build.sbt reproducing this issue? I tried with this example project and the output of

rpm -qp --scripts target/rpm/RPMS/noarch/simple-rpm-1.0-1.noarch.rpm

didn't contain any systemd related contents.

@zakcrawford I'm trying now with debian. Can you give a add build.sbt as well? :) I couldn't reproduce this with this example project either.

[ianjohnson]

I have tried to reproduce this issue with your example SBT projects but cannot exactly replicate my issue. I can't send you the SBT project I'm working on since it is proprietary. However, I'm using the following additonal plugins:

io.spray sbt-revolver v0.8.0 com.eed3si9n sbt-assembly v0.14.4 org.scoverage sbt-scoverage v1.5.0

These plugins are in the build.sbt file:

enablePlugins(JavaServerAppPackaging, RpmPlugin, SystemdPlugin)

And using:

mappings in Universal := {
  val universalMappings = (mappings in Universal).value
  val fatJar = (assembly in Compile).value
  val filtered = universalMappings filter {
      case (file, name) => ! name.endsWith(".jar")
  }
  filtered :+ (fatJar -> ("lib/" + fatJar.getName))
}

scriptClasspath := Seq( (jarName in assembly).value )

to package just the assembly.

This issue seems to occur even if I do not specify my own scriptlets.

[zakcrawford]

example here: https://github.com/zakcrawford/sbt-native-packager-examples/tree/master/simple-deb I had to remove this section from build.sbt and add a file in src/debian/DEBIAN/postinst to reproduce.

bashScriptConfigLocation := Some("${app_home}/../conf/jvmopts")
bashScriptExtraDefines += """addJava "-Dconfig.file=${app_home}/../conf/app.config""""

// how to override loader functions
linuxScriptReplacements += {
  val functions = sourceDirectory.value / "templates" / "custom-loader-functions"
  "loader-functions" -> TemplateWriter.generateScript(functions.toURL, Nil)
}

[muuki88]

This issue seems to occur even if I do not specify my own scriptlets

That's really weird @ianjohnson

I had to remove this section from build.sbt and add a file in src/debian/DEBIAN/postinst to reproduce

Thanks @zakcrawford that helps a lot. I'll take a look ASAP.

[muuki88]

I'm still not able to reproduce this :( Even when I checkout your project and check all the control scripts and the /etc/init/mukis-application-conf.conf everything is in it's place.

I'm using dpkg in version 1.18.10. What do you use @zakcrawford ?

dpkg --version                                           
Debian »dpkg« Paketmanagement-Programm Version 1.18.10 (amd64).

@levinson you mentioned in the same issue in #953 Can you give some additional information of your build system and if the sample project from zak has the incorrect or correct output?

[zakcrawford]

I'm on dpkg 1.18.14, and I haven't explicitly tested but I believe we saw the same issue on 1.17.5

[muuki88]

Thanks for the info @zakcrawford I'll try with these two versions. However I cannot imagine how this affects the files generated by sbt debian:stage. Speaking of

@zakcrawford / @ianjohnson do the files generated by debian:stage or rpm:stage produce the wrong files as well?

[muuki88]

@zakcrawford / @ianjohnson any updates on this one? If this is still an issue, it would be awesome if you are able to write a scripted test (see src/sbt-test) that reproduces this issue. Otherwise if you have fixed it, it would be nice to share your solution :)

[scheleaap]

I am experiencing the same or a very similar issue: a systemd script is appended to my custom postinst file.

I am using:

• Ubuntu 18.04.1
• sbt 1.3.4
• sbt-native-packager 1.5.2
• apt 1.6.12

This is the custom postinst file: https://github.com/scheleaap/rfid-jukebox/blob/master/scala/src/debian/DEBIAN/postinst

Instead, the resulting postinst in the .deb package looks like this:

Click to expand

``` #!/bin/sh ... ... exit 0 # ----- END OF SCRIPT, IGNORE THE FOLLOWING ----- # systemd support # # Adding service for management # $1 = service name # addService() { app_name=$1 app_sys_config="/etc/sysconfig/${app_name}" [ -e "${app_sys_config}" ] && . "${app_sys_config}" if [ -n "${PACKAGE_PREFIX}" ] ; then default_install_location="/usr/share/rfid-jukebox" actual_install_location="${PACKAGE_PREFIX}/${app_name}" sed -i "s|$default_install_location|$actual_install_location|g" "/usr/lib/systemd/system/${app_name}.service" fi systemctl enable "$app_name.service" } # # Start the service # $1 = service name # startService() { app_name=$1 systemctl start "$app_name.service" } # # Removing service from autostart # $1 = service name # stopService() { app_name=$1 systemctl stop "$app_name.service" systemctl disable "$app_name.service" } # # Restarting the service after package upgrade # $1 = service name # restartService() { app_name=$1 systemctl daemon-reload systemctl try-restart "$app_name.service" } addService rfid-jukebox || echo "rfid-jukebox could not be registered" startService rfid-jukebox || echo "rfid-jukebox could not be started" ```

I'd be interested in hearing if the same thing happens if you build it on your machine.