I would check the uwsgi config before restarting it, because if it is not valid, it should give warning and does not restart.
1) Can i solve this with writing some kind of plugin or using hook?
I've found a phase (as-user-atexit) to which i can attach a hook (exec some kind of shell commands), but i don't see how can i prevent restarting.
2) Or should i solved this on level overwriting systemd unit script?
you may want to check this http://uwsgi-docs.readthedocs.io/en/latest/FallbackConfig.html for an alternative approach
Related
I am using a job in Junkins to build my application (.ear) and then deploy it in Glassfish. I want to execute asadmin undeploy myApp before I deploy my application (the new version). The problem is in the 1st execution there is no application deployed so executing asadmin undeploy myApp generates an error. Any suggestion to deal with this situation. Any proposition is the most welcomed. Thank's.
EDIT :
Correct me if I am wrong in my method, maybe I am doing things wrong! Is this the right way to have a chain of production of a sowtware? Do I have to stop the server and restart it?
I never used Glassfish, but you could check if your app is deployed before to execute the undeploy.
If you know the port in which your app should be in execution, you could simply check with netstat or lsof.
EDIT:
Have a look to this doc (Example 2–3 Listing Applications), seems that you can see that with:
list-applications --type web
Regarding this:
Correct me if I am wrong in my method, maybe I am doing things wrong! Is this the right way to have a chain of production of a sowtware? Do I have to stop the server and restart it?
I think the correct answer is that it depends on the web server you are using (for example Glassfish provide the autodeploy). But generally, the approach works.
After watching some videos on Bash and with the help provided by Davide Patti, I figured out how to do it.
Knowing that I used the answer of Davide Patti and I thank him for his help I choosed to write my own answer for a simple reason: Patti's answer didn't work.
In order to test if an application is deployed and undeploy it if it is deployed I used the following Bash code which worked for me:
apps=`asadmin list-applications -t --user=admin --passwordfile=password.txt`
for app in $apps
do
if [ $app = "the_name_of_your_app" ]
then
asadmin --user=admin --passwordfile=password.txt undeploy the_name_of_your_app
fi
done;
PS: the content of password.txt is a single line: AS_ADMIN_PASSWORD=admin
Wondering if anyone knows how to install with tcp enabled? Something like below? I
yum install docker --tcp-enabled --host 0.0.0.0
I understand I can go and manual change OPTIONS in /etc/sysconfig/docker.
I am trying to provision a server with a fresh docker install through scripts and I do not want to log onto the box and make these changes, everytime a new version comes out. I also understand I can just use a script with sed/awk to do this, But just wondering if easier way, without having to maintain a script.
My preferred solution is to use /etc/docker/daemon.json. This will let you add options to just about any install.
Note that I don't believe this will unset options that were defined on the command line, it's designed to let you use both. Those command line options are defined by your startup script, which from your description is systemd on a RedHat/CentOS environment with /etc/sysconfig/docker injected environment variables (you won't see this on other platforms like Debian). So if you need to remove an option, you'll still need to update your /etc/sysconfig/docker.
I'm currently struggling with executing a simple command which I know works when I run it manually when logged in as either root or non-root user:
god -c path/to/app/queue_worker.god
I'm trying to run this when the server starts (I'm running Ubuntu 12.04), and I've investigated adding it to /etc/rc.local just to see if it runs. I know I can add it to /etc/init.d and then use update-rc.d but as far as I understand it's basically the same thing.
My question is how I run this command after everything has booted up as clean as possible without any fuzz.
Im probably missing something in the lifecycle of how everything's initialized, but then I gladly encourage some education! Are there alternative ways or places of putting this command?
Thanks!
You could write a bash script to determine when Apache has started and then set it to run as a cron job at a set interval...
if [ "$(pidof apache)" ]
then
# process was found
else
# process not found
fi
Of course then you'll have a useless cron job running all the time, and you'll have to somehow flip a switch once it's run once so it doesn't run again.. This should give you an idea to start from..
I have the following problem: I have an ANT-task in Jenkins-CI that (apparently) needs access to OSX' window server (it needs to show a window). After doing some research, it appears that only the currently logged in user and the 'root' user (or SUDO) can access OSX' window server.
The ANT task (Adobe ADL) is one that actually 'runs' a build, so it has to popup a screen.
I'm on a macBook running OSX 10.7.something (Lion), Jenkins 1.487, Ant 1.8.4.
What i have tried so far:
to start with, tried the 'barebone' < exec > task to invoke ADL. Works, but getting error that means that Jenkins running as daemon (with homedir /Users/shared/Jenkins/Home) cannot access OSX' Window Server.
Run Jenkins as myself, by changing USER_NAME, GROUP_NAME, JENKINS_HOME in the jenkins launchd.conf file: https://wiki.jenkins-ci.org/display/JENKINS/Thanks+for+using+OSX+Installer
this gives a lot of errors/trouble, which i tried to solve in communication with the creator of the Jenkins CI but, unfortunately to no avail.
Try to have Ant run an < exec > task (running a shell script) in which i try to sudo with a password using this sneaky way of passing a password to the stdinput: echo < password > | sudo -S < command > which is really bad, but as i'm running Jenkins locally (not reachable from the outside of my LAN) it's np.
Tried to have Ant run an < exec > task, using a 'redirector' with as inputstring my password. also superbad, but yea, i just want it to work. which it did not.
Tried a Jenkins SSH plugin: didn't work. I could, however, SSH to my own localhost using terminal, thing is, i don't know what the Jenkins SSH was trying to do (how can i figure that out anyway?) so i don't know why it wouldn't work.
Tried to have Ant run an SSHEXEC task (which, after some hours, finally worked. Ant for mac is borked, something with optional .jar tasks not being re-named correctly or something) but i'm getting a "com.jcraft.jsch.JSchException: Auth fail" which i googled for, and can't seem to resolve. only applicable solution is to have sshd accept password auths, did that, still got the same error.
I think what i want to accomplish was NOT worth the 2 days that i spent so far on this problem, although i learned a lot. However, i just want this to work and will not accept defeat, yet :)
My question: have you had to solve a similar problem, how did you go about it? are there any other methods i can try to solve this problem? Is there a method mentioned that should JUST _WORK_ and i did something wrong?
[edit] I have decided to go with the Jenkins standalone app, as i think (for me) this is a nicer solution in total, as my laptop is not a build server. Also, the Jenkins app can start at startup so it actually acts as a local server.
Just a quick guess: if you don't want the interactivity of the script, and the script can do without it, you can try to set the headless mode on the java command-line:
-Djava.awt.headless=true
I have decided to go with the Jenkins standalone app, as i think (for me) this is a nicer solution anyway, as my laptop is not a (headless) build server. Also, the Jenkins app can start at startup so it acts as a server too.
I have a two scripts in the Rails environment which have to run 24/7. I'm working on a remote server, so I need to start the scripts using ssh, which means I need to keep the ssh windows open all the time.
I'm searching for a simple way to run these scripts in the background so they aren't canceled as soon as I close the ssh connection.
I don't want to use screen. I think there must be simpler way to handle this. Isn't there?
I think the most basic solution would be nohup:
nohup myscript &> /dev/null &
You can disown a script:
ruby script.rb &!
STDOUT/STDERR are still attached to the current shell, but the ruby process isn't a child of the shell anymore, so it won't get killed if you close the terminal.
Check Daemons. It's a toolkit for converting a script to a controllable daemon.
You can use
runit
supervisord
For daemonizing
Or some ruby stuff: https://www.ruby-toolbox.com/#Background_Processing for background processing