Using Postgres 9.5 and the libpqxx c++ bindings, I want to launch a copy of postgres that is not installed on the users machine, but is instead packaged up in my application directory.
Currently, I am using pg_ctl.exe to start and stop the server, however when we do this, pg_ctl.exe seems to launch postgres.exe in a new terminal window.
I want it to launch postgres.exe in a headless state, but can't work out how.
I have tried enabling/disabling the logging collector, setting the logging method to a csv file (instead of stdout/stderr), and a couple of other logging related things, but I don't think the issue is the logging.
I have also tried running postgres.exe manually (without pg_ctl) and can get that to run headless by spawning it as a background process and redirecting the logs, but I would prefer to use the "pg_ctl start" api for the "wait for startup" (-w), and "timeout" (-t) options that it provides.
I believe you won't be able to do that with pg_ctl.
It is perfectly fine to start PostgreSQL directly through the server executable postgres.exe. Alternatively, you can use pg_ctl register to create a service and start the service.
In my use case, I was able to resolve the issue by running pg_ctl.exe using
CreateProcess, and providing the dwCreationFlags CREATE_NEW_PROCESS_GROUP | CREATE_NO_WINDOW.
I was originally using CREATE_NEW_PROCESS_GROUP | DETACHED_PROCESS, but DETACHED_PROCESS still allowed a postgres terminal to appear. This is because DETACHED_PROCESS will spawn the pg_ctl without a console, but any process that inherits stdin/stdout from pg_ctl will try to use it's console, and since there isn't one, one will be spawned. CREATE_NO_WINDOW however will launch the process with a conhost.exe, however the console will have no window. When the executables spawned by pg_ctl try to write to the terminal, they will successfully write to the console created by the conhost.exe which has no window.
I am now able to run pg_ctl from code with no console appearing.
Related
I have an akka-scala app that I'm able to build as a jar. I can then send the jar to a remote server via Jenkins. However, I don't know how to properly deploy the app.
The first problem is killing previous instances of my app. If in Jenkins I try to execute such commands as pkill -f %proc% or ps ax | grep ... | awk ... | xargs kill -9 via ssh, Jenkins finishes with return code -1 even if I add || true to the end of these commands.
The second problem is starting the app. I'm able to successfully run the jar with nohup java -jar ... & command, but it doesn't really start though I'm able to see it in the process list.
None of these problems occur if I execute commands manually (even via ssh).
My question is - what am I doing wrong? What is the proper way to perform such task? Am I using the wrong tool?
Consider using something like supervisord for starting/stoping your app and also restarting it in case of crash or server reboot.
I've done my development of play framework,and I have dist it to be a binary version uploaded to the server.
So,my problem is everytime i open it on ssh , it will shutdown when i logout , how to make it running until i shut it down manually?
You can use screen. It will start a new session that will stay open even if you disconnect from the server. You can then, on the next ssh, reconnect with screen -r -D. There are a ton of useful features such as creating multiple "screens" with ctrl+a and then c (see e.g. screen intro on digitalocean for more) so you can continue working on the server while the app is running
add nohup to your launch command to ensure it is not terminated when you exit your shell.
nohup exec /path/to/my/app/bin/myapp -Dhttp.port=8080
I'm trying to running OrientDB on Ubuntu. Currently, I'm running with bin/server.sh. This works fine except it runs foreground on shell. I can make it work background by Ctrl+Z and bg command, but this doesn't mean it's running as daemon.
I wish the program will keep running after I logout. And will be started again when it terminated unexpectedly or OS restarts. Like MS Windows Services. But the problem is I don't know how can I do this.
How can I run a program as a long-running service?
If you do not own the server, look into using the "screen" command. It will allow you to run a command, detach from the console where the command is running, then log out while leaving it running. You may reconnect to the running screen to see output or restart the script. Here's more info about the screen command:
http://www.manpagez.com/man/1/screen/
If you own the server, you should write an init script. It's not very hard, and you can set it up to run automatically on startup. The system will run the script with a "start" parameter when you want it to start, and a "stop" parameter when you want it to stop. Here's more detailed information:
http://www.novell.com/coolsolutions/feature/15380.html
If the command doesn't already detach from the console (run in daemon mode) then in the init script place the command in parenthesis to run in it's own shell. You will not see any output unless you pipe it to a file within the parenthesis.
(bin/server.sh >> /var/log/server.log)
I am trying to debug a program run as another user, using Netbeans. I can do this manually at the command line, by running sudo gdm and then attaching to the pid.
However, I would like to make use of the Netbeans GUI for easier/quicker/visual debugging. When I select the pid from the list of running processes, I get the error:
GDB failed to attach to process
When I attempt to attach manually (i.e. by running gdb at the command line - without sudo), I get an 'Operation not permitted', so I know Netneans is failing to attach because of permissioning.
Does anyone know how I can attach to processes being run by another user?.
BTW I am running all this on my dev machine at home (Ubuntu), so security is not an issue.
Have you tried running netbeans as the target user?
You can do "sudo -u username netbeans"
With that, you shouldnt have a problem attaching to the process. If the target user is in another computer, I would suggest ssh with X forwarding (ssh -X user#machine).
Actually, if the target (local) user has no password set, you can try changing your gdb command to "sudo -u username gdb" to start the debugger as that user.
When I start the `Paste' web server in daemon mode, it seems to kill off it's ability to reload when the timestamp of a source file is updated.
Here is how I start the daemon...
cd ${project} && ../bin/paster serve --reload --daemon development.ini; cd ..;
...which defeats one of the main points of using Paste (for me).
Has anyone come across this or know what I'm doing wrong?
To be complete, the file that I'm changing is a controller file.
The version is `PasteScript 1.7.3'
I believe that the two options are essentially incompatible, since the reloader stops the server with a SIGTERM and the daemon-ized server is impervious to that -- and since daemon is intended for running in a production environment, and reload for a development/debugging environment, I guess that their incompatibility is not seen as a big loss. I imagine a customized reloader, tailored to properly stop and restart the daemonized server, could certainly be developed, but I don't know of any existing one.
I had a similar problem and circumvented the problem. I currently have paster running on a remote host, but I am still developing, so I needed a means to restart paster, but manually by hand was too time consuming, and daemon didnt work. So I always had to keep a shell window open to the server and running paster without --daemon in there. Once I finished my work for that day, and i closed the shell, paster died, which is bad.
I circumvented that by running paster non daemonized in a "screen".
Simply type "screen" in your shell of choice, you will usually depending on your linux be presented with a virtual terminal, that will keep running even when you log out your remote session. Start paster as usually in your new "window" (the screen) with --reload but without daemon, and then detach the window, so you can return to your normal shell (detach = CTRL-A, then press D). You can re-enter that screen by typing "screen -r". If you would like to kill it, reconnect it (screen -r) and inside the screen type CTRL-A, then press K.
Hope that helps.