Create a parameter `STOP_WAIT_TIME` for the startup script
that configures the time in seconds to wait for a normal
shutdown. Because of #4941 we also send a shutdown half
way the countdown.
Fixes gh-7121
Expose the Required-Start and Require-Stop lines in the launch script
INIT INFO section as customizable embedded launch script properties.
This way one can express dependencies fron other init services by simply
changing the configuration in the build script.
Closes gh-7555
Previously, if the pathname of fully executable contained any space
characters, the launch script would fail to locate the jar file
This commit fixes this issue by quoting the jarfile.
Closes gh-7535
Allow support for custom Lyout implementations with both the Maven
and Gradle plugin. Implementations of `LayoutFactory` can now be
specified to allow customization of the layout. In addition a
layout may now implement `CustomLoaderLayout` if it wishes to
write custom loader classes.
See gh-7263
Previously, a relative PID folder was not handled correctly when
running stop, status, or force_reload. This meant that a service
could be started when configured to use a relative pid file, but
then could not be stopped.
The PID folder should be treated as relative to the service's jar
file. This commit updates stop, status, and force_reload to push the
jar file's directory so that this is now the case for those three
commands.
Closes gh-7092
This is an alternative to the fix made in 3b52909 which removed the
chown call entirely.
Prior to 3b52909, the ownership of $PID_FOLDER was always changed even
when its value was /var/run. This was problematic as it could prevent
other services from creating their pid folder or file.
When a sub-folder is used, changing its ownership so that it’s owned by
the user that will run the app is desirable as it limits access to the
folder. Rather than removing the chown call entirely, this commit
ensures that it only happens when a sub-folder is being used to hold the
pid file.
Closes gh-6532
Update the launch script so that it no longer changes ownership of the
PID_FOLDER.
Commit b24e736cfe had changed the chown
line from:
chown "$run_user" "$PID_FOLDER/${identity}"
to:
chown "$run_user" "$PID_FOLDER"
This meant that it was possible for the launch script to change
ownership of `/var/run` and prevent later processes from writing to
the folder.
Since PID_FOLDER is created before the chown statement, and that
the `checkPermissions` function runs to ensure that the PID file can
be written, it appears that the chown is not even required.
Fixes gh-6532
META-INF/INDEX.LIST files are pointless in an executable jar and
moving application classes from the root of the jar to
BOOT-INF/classes breaks the index, resulting in an
InvalidJarIndexException being thrown.
This commit updates the Repackager to automatically remove a
META-INF/INDEX.LIST file from a jar file that is being repackaged.
Closes gh-6601
In fact the folder was already created if the app is running as
a different user, but not if running as the current user, so it
was just a question of moving one line out of an if block.
Fixes gh-5986
Previously, arguments passed to the script were handled in one way
if a service was being started using start-stop-daemon and in another
way if start-stop-daemon wasn’t available or the application is being
launched in run mode. This meant that quoted arguments were only
handled correctly when the application was being started using
start-stop-daemon.
This commit updates the launch script so that argument handling is
the same across all three different way that the application can be
launched.
Closes gh-5942
Previously, if the folder which contained the jar was a symlink the
launch script would use the symlinked folder's name when determining
the default identity.
This commit updates the launch script so that symlinks are resolved
and the canonical name of the folder which contains the jar is used
when determining the script's default identity. The behaviour when
APP_NAME has been set is unchanged.
Closes gh-5679
Closes gh-5733
This commit improves the `InfoContributor` infrastructure as follows:
* `InfoEndpoint` no longer breaks its public API and returns a Map as
before
* `Info` is now immutable
* All properties of the build are now displayed. Since we control the
generation of that file, there is no longer a mode to restrict what's
shown
* Build info is now generated in `META-INF/build-info.properties` by
default
Closes gh-5734
The commit adds a new BuildInfo task that can be used to generate
a build.properties file, intended for inclusion in the Actuator's
info endpoint.
A default instance of the task can be configure using the plugin's
DSL:
springBoot {
buildInfo()
}
Additional properties can also be configured using the DSL:
springBoot {
buildInfo {
additionalProperties = [
'foo': 'bar'
]
}
}
When configured via the DSL, the Java plugin's classes task is
configured to depend on the build info task. Alternatively, if more
control is required, the task can be declared and configured manually:
task buildInfo(type: org.springframework.boot.gradle.buildinfo.BuildInfo) {
additionalProperties = [
'foo': 'bar'
]
}
classes {
dependsOn buildInfo
}
See gh-2559
This commit allows to generate the packaged artifact only locally by
adding a new `attach` property. If `attach` is set to `false` explicitly,
only the main artifact is installed/deployed.
Closes gh-5258
Previously, Repackager used Java 8 APIs without protecting against the
possibility of a NoSuchMethodError on earlier versions of Java.
This commit wraps the Java 8 APIs in try-catch blocks to ensure
that they do not cause a failure on Java versions before 8, while
still making full use of Java 8's capabilities when available.
Closes gh-5280
Previously, Animal Sniffer checking of spring-boot-loader-tools
was disabled as it failed with an NPE. This has been fixed in
Animal Sniffer 1.15.
This commit upgrades Animal Sniffer to 1.15 and adds the necessary
annotations to suppress failures for safe usage of sun.* and Java 7
APIs.
Note that UsesUnsafeJava has been copied from spring-boot and made
package-private. This retains the clearer intent of the custom
annotation (versus @IgnoreJRERequirement) while avoiding the change
in the build order that would be necessary for
spring-boot-loader-tools to use the annotation from spring-boot.
Closes gh-5284
This commit enhances the default launch script to allow the default
values for LOG_FOLDER and PID_FOLDER to be set at build time. They
can now be set using the logFolder and pidFolder properties
respectively.
Closes gh-4787
When an application is run as an executable archive with nested jars,
the application's own classes need to be able to load classes from
within the nested jars. This means that the application's classes need
to be loaded by the same class loader as is used for the nested jars.
When an application is launched with java -jar the contents of the
jar are on the class path of the app class loader, which is the
parent of the LaunchedURLClassLoader that is used to load classes
from within the nested jars. If the root of the jar includes the
application's classes, they would be loaded by the app class loader
and, therefore, would not be able to load classes from within the
nested jars.
Previously, this problem was resolved by LaunchedURLClassLoader being
created with a copy of all of the app class laoder's URLs and by
using an unconventional delegation model that caused it to skip its
parent (the app class loader) and jump straight to its root class
loader. This ensured that the LaunchedURLClassLoader would load both
the application's own classes and those from within any nested jars.
Unfortunately, this unusual delegation model has proved to be
problematic. We have seen and worked around some problems with Java
Agents (see gh-4911 and gh-863), but there are others (see gh-4868)
that cannot be made to work with the current delegation model.
This commit reworks LaunchedURLClassLoader to use a conventional
delegate model with the app class loader as its parent. With this
change in place, the application's own classes need to be hidden
from the app class loader via some other means. This is now achieved
by packaging application classes in BOOT-INF/classes (and, for
symmetry, nested jars are now packaged in BOOT-INF/lib). Both the
JarLauncher and the PropertiesLauncher (which supports the executable
jar layout) have been updated to look for classes and nested jars in
these new locations.
Closes gh-4897
Fixes gh-4868
Commit 5a1ee6eb added support for disabling use of start-stop-daemon
via a placeholder in the default launch script. Unfortunately, that
placeholder was subsequently broken in 81a47639.
This commit reinstates the placeholder and adds tests to verify that all
of the placeholders in the launch script can be replaced and that they
have the required default values. Furthermore, it also allows the use of
start-stop-daemon to be configured via USE_START_STOP_DAEMON in an
app’s .conf file. This allows the configuration to be changed after the
app has been built.
Closes gh-4985
Previously, the default launch script would send SIGTERM once and then
wait for up to 60 seconds for the app to have stopped. If the service
was stopped immediately after being started the first SIGTERM would
occasionally be ignored (presumably because the JVM was not yet in a
state to handle it) causing the service stop request to fail.
This commit updates the launch script to resend SIGTERM to the process
if it's still running 30 seconds after the first SIGTERM was sent.
Closes gh-4941
$arguments needs to be split on spaces so it can’t just be wrapped
in quotes. This commit updates arguments to be an array that is then
expanded ("{arguments[@]}"). The use of @ and double quotes means that
it is expanded into all elements individually quoted.
See gh-4866
81a4763 introduced a regression when multiple RUN_ARGS or JAVA_OPTS were
configured. Rather than the JVM being launched with multiple arguments
all of the RUN_ARGS or JAVA_OPTS were passed as a single argument. This
caused unexpected behaviour and typically caused the application to fail
to start.
This commit updates the quoting of the arguments the are supplied when
launching the app using start-stop-daemon so that space-separated
entries in RUN_ARGS and JAVA_OPTS remain separate.
Closes gh-4866
Previously, the launch script used which to determine the availability
of start-stop-daemon. which isn’t available by default on all OSs.
For example, it’s not available by default on CentOS 5.
This commit updates the launch script to use type when determining if
start-stop-daemon is available. This improves the portability of the
script and makes the use of type consistent throughout the script.
Closes gh-4925
Previously, the launch script would wait for the pid file to exist
before continuing. This didn’t work 100% of the time as it left a
window where the file had been created but the PID had not been written
to it that could result in an incorrect report of the app failing to
start.
This commit updates the script to wait for the file to have a size
greater than zero before continuing. This ensures that the pid has
been written to the file before the pid is read from the file and used
to check that the process is running.
Closes gh-4923
Exiting with 0 when cd fails is likely to be incorrectly interpreted
as success so we should exit with a non-zero value. Ideally, the init
script status action would exit with 4 but, at the point when
the cd is performed, we don’t even know if we’re running as an init
script. Exiting with 1 seems to be a reasonable compromise as it’s
fine for the non init-script case as well as being correct for all
init script actions other than status.
See gh-4653
Allow users to easily opt-opt of using the start-stop-daemon in the
launch script. This may be required on distros that include older
versions.
Fixes gh-4732
There’s a race condition in start-stop-daemon when --make-pidfile and
--background are used together [1]. This race condition can lead to the
command returning before the PID file has been created. The missing PID
file then causes the launch script to incorrectly report that the
service failed to start.
This commit updates the launch script to wait for up to 10 seconds for
the PID file to be created when start-stop-daemon is used to launch the
app.
Closes gh-4524
[1] https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1036899
Update the launch script so that the PID file is not longer removed at
the beginning of the stop method. Prior to this commit if a service
wasn't able to stop on the first run, it wasn't possible to use the
launch script anymore.
Fixes gh-4369
Closes gh-4371
The HUP signal was being used to stop the service and for some reason,
sometimes it was being ignored. This commit change forces the use of the
TERM signal (the default signal of kill).
Fixes gh-4378
Closes gh-4414
By default, start-stop-daemon will chdir to the root directory before
starting the process. This prevents an application.properties file that
sits alongside the jar from being found.
This commit updates the call to start-stop-daemon to use --chdir to
set the working directory to that of the jar that’s being launched.
Closes gh-4281
Phillip Webb
Kazuki Shimizu
Gaurav Rawat
Spring Buildmaster
Johnny Lim
Lucas Saldanha
Alessandro Falappa
Andy Wilkinson
Pei-Tang Huang
Dave Syer
Christian Koops
Stephane Nicoll
Plamen Totev
Christian Flamm
Christian Brunotte
Uwe Schaefer
Johannes Edmeier
Michitomo Nakahara
mnhock
吉田 尚弘
Pedro Vilaca
ZakarFin