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.

Sign up for GitHub

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

fix use of app_name and exec vars in systemv start-rpm-template #537

Merged
merged 1 commit into from
Apr 4, 2015
Merged

fix use of app_name and exec vars in systemv start-rpm-template #537

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 7 additions & 9 deletions .../com/typesafe/sbt/packager/archetypes/java_server/systemloader/systemv/start-rpm-template
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,8 +34,6 @@
# $JAVA_OPTS used in $RUN_CMD wrapper
export JAVA_OPTS

prog="${{exec}}"

# FIXME The pid file should be handled by the executed script
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why remove this and insert ${{app_name}} by hand?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought it helped the readability of the file. Seeing as it’s already templated, it seems easier to see where the app_name variable flows to, rather than having the indirection of prog.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm. I think it doesn't matter. The main point for creating a new variable is to be able to rename the replacement placeholder in one place. However we shouldn't do this (as any client could rely on this). So readability wins :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean change the var name app_name in the future? As you say, that would be pretty disastrous for backwards compatibility :)

# The pid can be filled in in this script
PIDFILE=/var/run/${{app_name}}/running.pid
Expand All @@ -50,15 +48,15 @@ fi


# smb could define some additional options in $RUN_OPTS
RUN_CMD="${{chdir}}/bin/${{app_name}}"
RUN_CMD="${{chdir}}/bin/${{exec}}"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch! thanks


[ -e /etc/sysconfig/$prog ] && . /etc/sysconfig/$prog
[ -e /etc/sysconfig/${{app_name}} ] && . /etc/sysconfig/${{app_name}}

lockfile=/var/lock/subsys/$prog
lockfile=/var/lock/subsys/${{app_name}}

start() {
[ -x $RUN_CMD ] || exit 5
echo -n $"Starting $prog: "
echo -n $"Starting ${{app_name}}: "
cd ${{chdir}}

# FIXME figure out how to use daemon correctly
Expand All @@ -81,8 +79,8 @@ start() {
}

stop() {
echo -n $"Stopping $prog: "
killproc -p $PIDFILE $prog
echo -n $"Stopping ${{app_name}}: "
killproc -p $PIDFILE ${{app_name}}
retval=$?
[ $retval -eq 0 ] && rm -f $lockfile
return $retval
Expand All @@ -103,7 +101,7 @@ force_reload() {

rh_status() {
# run checks to determine if the service is running or use generic status
status -p $PIDFILE -l $lockfile $prog
status -p $PIDFILE -l $lockfile ${{app_name}}
}

rh_status_q() {
Expand Down