I used to run my pyramid server as a daemon with the pserve --daemon command.
Given that it's deprecated, I'm looking for the best replacement. This link recommends to run it with screen or tmux, but it seems too heavy to just run a web server. Another idea would be to launch it with setsid.
What would be a good way to run it ?
Create a service file in /etc/systemd/system. Here a example (pyramid.service):
[Unit]
Description=pyramid_development
After=network.target
[Service]
# your Working dir
WorkingDirectory=/srv/www/webgis/htdocs/app
# your pserve path with ini
ExecStart=/srv/www/app/env/bin/pserve /srv/www/app/development.ini
[Install]
WantedBy=multi-user.target
Enable the service:
systemctl enable pyramid.service
Start/Stop/Restart the service with:
systemctl start pyramid.service
systemctl restart pyramid.service
systemctl stop pyramid.service
The simplest option is to install supervisord and setup a conf file for the service. The program would just be env/bin/pserve production.ini. There are countless examples online of how to do this.
The best option is to integrate with your system's process manager (systemd usually, but maybe also upstart or sysvinit or openrc). It is very easy to write a systemd unit file for starting pserve and then it will be started/stopped along with the rest of your system. Log files are even handled automatically in these cases.
Related
Which config files could disable the automatically starting ssh server, so a headless connect becomes impossible?
I need to know the config files that might interfere with the ssh server to normally start up at boot.
I believe that you are looking for the following commands (assuming you are running the last version of raspbian):
sudo systemctl stop sshd
sudo systemctl disable sshd
sudo systemctl mask sshd
stop Basically stops the service immediately. disable disables the service from starting at bootup. Additionally, mask will make it impossible to load the service.
Digging deeper into what each command does, on modern linux distributions there are configuration files for each service called unit files. They are stored (usually) in /usr/lib/systemd. These are basically the evolution of scripts to start services.
the stop command just calls the sshd.service unit file with a stop parameter, in order to shut down the server.
the disable (or enable) command removes(or creates) a symlink of the unit file in a directory where systemd looks into when booting services (usually, /etc/systemd/system).
systemctl mask creates a symlink to /dev/null instead of the unit file. That way the service cant be loaded.
I just downloaded jbpm server from JBPM.
it starts by running "jbpm-server/bin/standalone.sh" this. But i want to start jbpm as ubuntu's service like---> systemctl start jbpm.
can anyone provide me details to create startup script for this.
You should create a file in your systemd directory, for example /etc/systemd/system/change_me.service and fill it with a basic setup like:
[Unit]
Description=Your service's description
[Service]
ExecStart=/path/to/executable.sh
[Install]
WantedBy=multi-user.target
Then you should reload your systemd configuration in order to update it with the new service via
sudo systemctl daemon-reload
And then start it
sudo systemctl start change_me
If you want a more granular control over your systemd's service file you should read the man page via:
man systemd.service
I am working to create a service that triggers a script upon boot. The script then installs and activates a piece software. I only want this service to run once so that it installs the software on initial boot. This is being built into an AMI for standard deployment in an enterprise.
I currently have the following:
/etc/systemd/system/startup.service (executable using chmod +x; enabled using "systemctl enable startup.service")
/var/tmp/LinuxDeploymentScript.sh
The service contains:
[Unit]
After=remote-fs.target
[Service]
Type=oneshot
User=root
ExecStart=/var/tmp/LinuxDeploymentScript.sh
[Install]
WantedBy=multi-user.target
When I test the service by using systemctl start startup.service it runs successfully, but when I leave it enabled and reboot the system, it fails to activate:
Screenshot of failure log
Any help would be great. I have a thought that it could be my After= setting may not be far enough into the computer spinning up to be successful.
I'm running Ubuntu 18.04 and I've installed haproxy 1.8.8. I want to modify the config so that the "-f" option will read a directory rather than a single haproxy.cfg file.
I see /lib/systemd/system/haproxy.service and also /etc/init.d/haproxy were installed. I think systemd is managing haproxy. But I've read that I'm not supposed to modify the installed haproxy.service.
I copied haproxy.service to /etc/systemd/system/ and edited it there. The changes I made were not picked up when I ran sudo systemctl daemon-reload; sudo service haproxy restart.
Which file do I need to modify and then get systemd to recognize the changes? TIA
As you suspected, you should not edit the unit-files (provided by the OS packager) directly. You can supply a drop-in-snippet using the command
systemctl edit haproxy
and customize the relevant directives (ExecStart)
I've developed a Netty application that allows connections through TCP from various devices. However i'm not entirely sure what is the best way to deploy the application for production use. Right now i package it up in a JAR file and run a screen session on the target server like so:
screen -S Nettyjava -jar Server-Netty.jar
Is this the recommended way to deploy it or is screen the best option available?
screen is not the right tool to run a service in production. If the system has to reboot, you will have to relaunch the service by hand. On most current linux distributions, you can handle this with a systemd service unit file. This allows you to define the working directory, the user, the command to run... Here is an example taken from the Unix & Linux StackExchange question configure java daemon with systemd
[Unit]
Description=Some job
After=network.target
[Service]
WorkingDirectory=/home/user/tmp/testout
SyslogIdentifier=SocketTest
ExecStart=/bin/sh -c "exec java -jar /home/user/programming/tests/java/core/SocketTest/SocketTest.jar"
User=dlt
Type=simple
[Install]
WantedBy=multi-user.target
A good practice consists in creating a specific user for running the service and to restrain his right on the filesystem.