Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow to override upstart script templates #182

Closed
ljwagerfield opened this issue Mar 4, 2014 · 11 comments
Closed

Allow to override upstart script templates #182

ljwagerfield opened this issue Mar 4, 2014 · 11 comments

Comments

@ljwagerfield
Copy link

The ability to override bin templates was recently added here:

699e24b

Is it possible to add something similar for Upstart scripts? The existing script does not work for Ubuntu 13.10, so I am having to add my own. However, JavaAppStartScript is hardcoded to use the built-in templates.

  def templateUrl(templateName: String, loader: ServerLoader, template: Option[URL] = None): Option[URL] = template orElse {
    Option(loader match {
      case Upstart if (upstartScripts contains templateName) =>
        getClass getResource ("upstart/" + templateName + "-template")
      case SystemV if (systemvScripts contains templateName) =>
        getClass getResource ("systemv/" + templateName + "-template")
      case _ => null
    })
  } 

So the following code I have added to build.sbt has no effect:

linuxStartScriptTemplate in Linux := sbt.url((baseDirectory.value / "src" / "main" / "resources" / "config" / "upstart.conf").toURI.toString)
@aparkinson
Copy link
Contributor

If the Upstart scripts don't work with 13.10 then there is a regression within sbt-native-packager. Could you create a separate ticket with details about the problem with Upstart so we can look into it.

In the mean time I will double check within my own test VM's. I'm presently using Ubuntu 12.04

@muuki88
Copy link
Contributor

muuki88 commented Mar 4, 2014

You should be able to override this with

linuxStartScriptTemplate in Debian := ...

Or you put a file src/templates/start . Both solutions assume you want to override the init script, not the bash script.

Can you provide some details on the application you are trying to run?

Other errors found

Still I found some issues while going through the code.

  • template is always under etc/templates/start we should care about differnt scripts
  • the default setting for the template is irrelevant, I think, as this is used as a fallback anyway. ( Recheck that )

@muuki88 muuki88 added this to the 0.7.0 - Server archetype milestone Mar 4, 2014
@ljwagerfield
Copy link
Author

@aparkinson apologies: on further inspection the underlying issue was caused by the absence of a packageSummary in Linux setting, which produced an erroneous description "" in the Upstart job.

@muuki88 thanks for the info. I'll try this again if/when I have a need to use custom Upstart job templates - the above resolution means I can keep with the existing template :)

@muuki88
Copy link
Contributor

muuki88 commented Mar 5, 2014

Thanks for sharing. I leave this ticket open as IMHO we should provide at least a warning on an empty packageSummary in Linux if it leads to a not-working upstart conf.

@jsuereth
Copy link
Member

Hmm, I think maybe we should open a new ticket about packageSummary in Linux warning.

@ljwagerfield
Copy link
Author

This works fine for me, although I am just about to open another ticket asking for a similar override functionality for the other Debian scripts (specifically debianMakePostinstScript). In this case, my requirements deviate from the standard functionality as so:

My users are required to configure the application before the service can be started. A sensible default configuration cannot be provided, as passwords are required etc. Consequently, having the post-install script start the service is a bad idea (in this instance). The script I actually want to run looks more like:

initctl reload-configuration

echo
echo Post-installation tasks
echo -----------------------
echo
echo "1. Update the configuration file for this environment (new installs only)"
echo
echo "   /usr/share/${{app_name}}/conf/environments/[environment].conf"
echo
echo "2. Run the post-install script (new installs & upgrades)"
echo
echo "   /usr/share/${{app_name}}/bin/post-install -e conf/environments/[environment] -a \"[optional_args]\""
echo

I am currently achieving this through the following hack in my build.scala:

  def packagerSettings: Seq[Setting[_]] =
    packageArchetype.java_server ++ Seq(
      serverLoading := Upstart,
      debianMakePostinstScript <<= (target in Universal, serverLoading, debianScriptReplacements) map makeDebianPostInstallScript()
    )

  def makeDebianPostInstallScript()(tmpDir: File, loader: ServerLoader, replacements: Seq[(String, String)]): Option[File] = {
    val scriptName = "postinst"
    val template = Some(getUrl("src/main/resources/postinst-template"))
    JavaAppStartScript.generateTemplate(scriptName, loader, replacements, template) map { scriptBits =>
      val script = tmpDir / "tmp" / "bin" / ("debian-" + scriptName)
      IO.write(script, scriptBits)
      script
    }
  }

@muuki88
Copy link
Contributor

muuki88 commented Mar 10, 2014

You can do this easily by placing your postinst file into src/debian/DEBIAN.
See #190

@ljwagerfield
Copy link
Author

Thanks, will check this out later today :)

@ljwagerfield
Copy link
Author

Tested this just now - am I right in saying this way does not support substitutions? I get the following error around ${{app_name}}:

/var/lib/dpkg/info/my-site.postinst: 134: /var/lib/dpkg/info/my-site.postinst: Bad substitution
dpkg: error processing my-site (--install):
 subprocess installed post-installation script returned error exit status 2

@muuki88
Copy link
Contributor

muuki88 commented Mar 12, 2014

The replacements for linux haven't been completly unified. The DebianPlugin has still it's own replacements:

    "author" -> author,
    "descr" -> descr,
    "name" -> name,
    "version" -> version

So you should try ${{name}}. @jsuereth Unifying this shouldn't be to hard. This actutally could make sense in the RC1

@ljwagerfield
Copy link
Author

Brilliant, thanks!

muuki88 added a commit that referenced this issue Mar 12, 2014
muuki88 added a commit that referenced this issue Mar 12, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants