Logs stucks when deployment is done through teamcity - java

Recently we migrated to Teamcity deployment from manual process. Ours is java application on linux server.
Whenever deployment is done through Teamcity, logs are stuck i.e. after shutdown log messages nothing else is printed in the logs. Then we run manual stop and start scripts on the server to get the logs running.
Looks like somehow Teamcity locks log file and doesn't release it.
How to overcome it?
In Teamcity, deploy step is defined as below:
REMOTE_PATH="/opt/app/$ARTIFACT/releases/teamcity"
cd $TEAMCITY_REPO_HOME/$ARTIFACT/build/libs
echo "Uploading artifact"
ssh $UAT_HOST -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no "mkdir -p $REMOTE_PATH"
scp -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no $ARTIFACT.jar $UAT_HOST:$REMOTE_PATH
echo "Stopping service"
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no $UAT_HOST "sh /opt/app/$ARTIFACT/stop.sh"
sleep 3s
echo "Copying new artifact"
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no $UAT_HOST "cp $REMOTE_PATH/$ARTIFACT.jar /opt/app/$ARTIFACT"
sleep 6s
echo "Starting service"
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no $UAT_HOST "sh /opt/app/$ARTIFACT/start.sh"

Taking ideas from above comments of Andy Dufresne, I created one deploy script as below:
This single script stops server, takes backup of current artifact, copies new build and then executes start script to start the server.
#!/bin/bash
#check for correct number of arguments
if [ "$#" -ne 1 ]; then
echo "Incorrect number of arguments, exiting..."
exit 1
fi
ARTIFACT=$1
cd "/opt/app/$ARTIFACT"
echo $(pwd)
echo "Stopping service"
bash stop.sh
sleep 3s
echo "Tagging artifact with release"
cp "releases/teamcity/$ARTIFACT.jar" "releases/teamcity/$ARTIFACT`date +'_%y_%m_%d'`.jar"
echo "Deleting old releases"
cd "releases/teamcity" && \
ls | grep -v '/$' | head -n -6 | xargs -d '\n' -r rm -- && \
cd "/opt/app/$ARTIFACT" && \
ls -l "releases/teamcity"
echo "Copying new artifact"
cp "releases/teamcity/$ARTIFACT.jar" .
echo "Starting service"
bash start.sh
sleep 2s
This script is called from team-city in its build steps(previously stopping server, copying artifact and starting server all were done by teamcity explicitly as outlined in the question.)
Now teamcity build step looks concise as under and WORKS as expected(that important !!!):
REMOTE_PATH="/opt/app/$ARTIFACT/releases/teamcity"
cd $TEAMCITY_REPO_HOME/$ARTIFACT/build/libs
echo "Uploading artifact"
ssh -o "StrictHostKeyChecking=no" "$UAT_HOST" "mkdir -p $REMOTE_PATH"
scp -o "StrictHostKeyChecking=no" "$ARTIFACT.jar" "$UAT_HOST:$REMOTE_PATH"
echo "Deploying artifact"
ssh -o "StrictHostKeyChecking=no" "$UAT_HOST" "sh /opt/app/$ARTIFACT/deploy.sh $ARTIFACT"

Related

War file automated deployment

So I deploy war files on a Linux box using java automatically
and the same commands are always used
ps -ef | grep java
kill - 9 (java process)
java -jar ROOT.war &>/dev/null &
However, I get different versions for it so like
ROOT_1.0.2.war
ROOT_1.0.3.war
ROOT_1.0.4.war
ROOT_1.0.5.war
I want the script to see the new .war and deploy it automatically
and keep it deployed which is why I use &>/dev/null & so it runs in the till it is killed again till the new version is put in that directory
echo Enter the name of the process you want to kill eg ROOT.war?
enter code here
read process
##Kill selected process
file="$process"
if [ -f "$file" ];
then
pkill -9 -f $process
echo process stopped >> satrixWar.txt
sleep 3s
## Start Up selected process
echo Enter the name of the process you want to start
read process2
java -jar $process2 &>/dev/null &
echo process starting up>> satrixWar.txt
else
echo "Process $process does not exist" >&2
fi
##Confirm new proess is up
echo What is currently installed >> satrixWar.txt
ps -ef | grep $process2 >> satrixWar.txt
mail -a text file path -s "name"
"email.com" < /dev/null
rm -rf War.txt

Unable to stop java process using SIGINT on Linux

I am building a virtual machine for some tests that needs to run among other things DynamoDb web service. VM is based on stock Ubuntu 16.04 64bit.
This is the part of provisioning script that installs DynamoDB:
# Install local instance of DynamoDB
DARCHFILE='/tmp/dynamodb_local_latest.zip'
wget -P /tmp/ -nv https://s3-us-west-2.amazonaws.com/dynamodb-local/dynamodb_local_latest.zip
sudo unzip -q "$DARCHFILE" -d /usr/local/lib/dynamodb
sudo mkdir -pv /var/lib/dynamodb/
sudo mkdir -pv /var/log/dynamodb/
sudo apt-get install -y openjdk-8-jdk
This is the script that executes DynamoDb:
#!/bin/bash
# -*- mode: sh -*-
# vi: set ft=sh :
java -Djava.library.path=/usr/local/lib/dynamodb/DynamoDBLocal_lib/ \
-jar /usr/local/lib/dynamodb/DynamoDBLocal.jar \
-dbPath /var/lib/dynamodb/ \
-optimizeDbBeforeStartup \
-port 8000 > /var/log/dynamodb/trace.log 2> /var/log/dynamodb/error.log &
echo $! > /var/run/dynamodb.pid
Now if I try to stop the process using the "nice one" SIGINT (equivalent of Ctrl+C) it does nothing. Only sending SIGTERM works.
So this does nothing:
sudo kill -s SIGINT $(< /var/run/dynamodb.pid)
As we can confirm by executing this:
sudo ps -x | grep $(< /var/run/dynamodb.pid)
While this works just fine:
sudo kill -s SIGTERM $(< /var/run/dynamodb.pid)
On the other hand if I start dynamodb manually and don't send it to the background Ctrl+C does work.
So what gives? Is it my mistake or behavior by design?
Thanks

spring boot init.d script start-stop-daemon: unrecognized option --no-close

after symlink my app to the /etc/init.d/myappname.
/etc/init.d/myappname start gives "Failed to start"
/var/log/appname.log tells
"start-stop-daemon: unrecognized option '--no-close'"
when i remove the --no-close, the jar becomes corrupted and cannot run anymore. i am struck.
bdw my jar is fullyexecutable jar. i.e., when i run the jar alone it starts up the springboot normally.
whats going wrong here?
EDIT:
do_start() {
working_dir=$(dirname "$jarfile")
pushd "$working_dir" > /dev/null
if [[ -n "$run_user" ]]; then
mkdir "$PID_FOLDER" &> /dev/null
checkPermissions || return $?
chown "$run_user" "$PID_FOLDER"
chown "$run_user" "$pid_file"
chown "$run_user" "$log_file"
if [ $USE_START_STOP_DAEMON = true ] && type start-stop-daemon > /dev/null 2>&1; then
arguments=(-Dsun.misc.URLClassPath.disableJarChecking=true $JAVA_OPTS -jar $jarfile $RUN_ARGS "$#")
start-stop-daemon --start --quiet \
--chuid "$run_user" \
--name "$identity" \
--make-pidfile --pidfile "$pid_file" \
--background --no-close \
--startas "$javaexe" \
--chdir "$working_dir" \
-- "${arguments[#]}" \
>> "$log_file" 2>&1
await_file "$pid_file"
else
su -s /bin/sh -c "$command >> \"$log_file\" 2>&1 & echo \$!" "$run_user" > "$pid_file"
fi
pid=$(cat "$pid_file")
else
checkPermissions || return $?
$command >> "$log_file" 2>&1 &
pid=$!
disown $pid
echo "$pid" > "$pid_file"
fi
[[ -z $pid ]] && { echoRed "Failed to start"; return 1; }
echoGreen "Started [$pid]"
}
I assume you already created an executable JAR of your Spring Boot app.
Copy your app to /var/appname/appname.jar
Make sure it's given execute permission:
sudo chmod +x "/var/appname/appname.jar"
Create a config file /var/appname/appname.conf with the following content
USE_START_STOP_DAEMON=false
Follow instructions from Spring Boot Reference Guide
To install a Spring Boot application as an init.d service simply create a symlink:
$ sudo ln -s /var/appname/appname.jar /etc/init.d/appname
Once installed, you can start and stop the service in the usual way. For example, on a Debian based system:
$ service appname start
i finally solve this problem.
--no-close is a parameter that was "recently" added to start-stop-daemon
http://manpages.ubuntu.com/manpages/wily/man8/start-stop-daemon.8.html
I run my app.jar on Ubuntu 12.04 LTS that has
start-stop-daemon 1.16.1.2 for Debian
You could know what version you are running using:
start-stop-daemon --version
on linux console.
I downloaded a newer version of start-stop-daemon on
https://pkgs.org/ubuntu-14.04/ubuntu-main-amd64/dpkg_1.17.5ubuntu5_amd64.deb.html
Install the deb package and spring boot jar will finally run.
Run "service myappname start" as mentioned in the document http://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html
There is a difference between /etc/init.d/myappname start and server myappname start

How to run a script in user mode inside an executable jar that is executed as root?

I want to run the following script within a Java executable jar on the Raspberry Pi.
the script (= stream.sh):
#!/bin/sh
raspivid -fps 25 -w 640 -h 360 -vf -n -o - -t 999999 |cvlc -vvv stream:///dev/stdin --sout '#rtp{sdp=rtsp://:8554/cam.sdp,rtcp-mux}' :demux=h264
the Java code:
Runtime.getRuntime().exec("sh stream.sh"));
The problem is that the jar must be run with sudo and the vlc command doesn't accept sudo. Neither the script or the Java code contain sudo but as the jar is executed as sudo, vlc still gives the error "VLC is not supposed to be run as root...".
What is the easiest way to make the script run in user mode inside the jar?
I would use su -l $LOGIN -c $CMD or sudo -u $LOGIN $CMD.
Runtime.getRuntime().exec("sudo -u myuser sh stream.sh"));
man sudoers has all the information you need.
You need to change /etc/sudoers

Starting Screen with a Command

I need to be able to start up a screen without connecting to it, but it also needs to run my start.sh script which contains the java line to start Minecraft.
screen -d -m new3 -c start.sh
Is what I've been trying to use, but it never runs start.sh
In a snippet of code I found on line it seems to do what I want but I need some help
mc_start() {
cd $MCPATH
as_user "cd $MCPATH && screen -dmS $SCREEN $INVOCATION"
#
# Waiting for the server to start
#
seconds=0
until ps ax | grep -v grep | grep -v -i SCREEN | grep $SERVICE > /dev/null
do
sleep 1
seconds=$seconds+1
if [[ $seconds -eq 5 ]]
then
echo "Still not running, waiting a while longer..."
fi
if [[ $seconds -ge 120 ]]
then
echo "Failed to start, aborting."
exit 1
fi
done
echo "$SERVICE is running."
}
I think this is because your command is wrong. I'm assuming that you want to create a new session named new3 and detach from that
screen -d -m -S new3 ~/start.sh
Afterwards you can run the following command to connect back to your session.
screen -R new3

Categories