I used systemd (ubuntu 16.0.4 LTS) to start MyServer at service (if reboot or crash ocurred, restart automatically by systemd).
It's work fine but it's never generate logs any more!
My server generate logs at file "MyServerLogs" and if this file not exist, create new one (in same running directory).
Also MyServer watch a directory (that create by itself in same running directory) for file creation. This does not work either!
When MyServer run by systemd service, It can not create file, write to file and watch directory for file creation any more. But why?.
I develop MyServer with c++ and beginner of systemd and unit files.
I put MyServer at:
/usr/bin/MyServer
and my unit file
[Unit]
Description=Virtual Distributed Ethernet
After=syslog.target
After=network-online.target
After=network.target
[Service]
ExecStart=/usr/bin/MyServer
Restart=always
StandardOutput=syslog
[Install]
WantedBy=multi-user.target
Thanks for any help.
Related
I have a node.js script in my directory on my raspberry pi /home/pi/my/app/here/app.js
When I navigate using cd my/app/here and run node app.js my script executes without any problems. However, when I try to execute this script from a service in systemd I get an code=exited, status=203/EXEC error.
Here is my service file:
[Unit]
Description=App
After=network.target
[Service]
Type=simple
User=pi
ExecStart=/user/bin/node /home/pi/my/app/here/app.js
WorkingDirectory=/home/pi/my/app/here
Restart=on-failure
[Install]
WantedBy=multi-user.target
This is really my first time using systemd and most of what I have found has been through research online and other SO posts. So I am sure I am missing something pretty silly, but any help on getting my service to run would be much appreciated.
What am I missing here?
Put a hash bang in the file
#!/usr/bin/env node
And just ensure the x bit is set.
Can rqlite run as a Linux service? so it can be start/stop/restart with systemctl command. Any example of the service file would be appreciated.
A basic systemd service file with ExecStart set to your rqlited command should suffice. See example below.
A more thorough service file can be found in the very good Arch User Repo package of rqlite.
It also includes creation of rqlite system user and directory and more security considerations.
Information on how to form a cluster with rqlite started as a service can be found on XenGi, the packager's page. It makes use of an environment file that sets the arguments of rqlite nodes.
[Unit]
Description=
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
ExecStart=/usr/bin/rqlited -http-addr 0.0.0.0:4001 -raft-addr 0.0.0.0:4002 /path/to/datadir
User=youruser
ExecReload=/bin/kill -HUP $MAINPID
KillSignal=SIGTERM
Restart=always
[Install]
WantedBy=multi-user.target
I'm trying to start a task when bluetooth is ready on a raspi (running raspbian 10 - buster) with systemd.
I've added the file /lib/systemd/system/my.service with this content
[Unit]
After=bluetooth.target
[Service]
Type=idle
ExecStart=/root/my.sh
[Install]
Wants=bluetooth.target
When I look at what happens on startup with the graph created by systemd-analyse plot, I see that my service is started way before the bluetooth.target unit is activated.
But when I check with systemctl show my.service, it says
...
After=basic.target bluetooth.target system.slice systemd-journald.socket sysinit.target
...
So can someone explains me why my service doesn't start after bluetooth.target?
Thanx
[edit]
I've followed advice from #ukBaz and moved my service file to /etc/systemd/system and moved the Wants stanza to the Unit section (actually I changed it to 'Requires').
So my file now contains
[Unit]
After=bluetooth.target
Requires=bluetooth.target
[Service]
Type=idle
ExecStart=/root/my.sh
[Install]
WantedBy=multi-user.target
Now my service starts after bluetooth.target... but bluetooth.target gets started very early!
And systemctl show bluetooth.target tells me 'After=bluetooth.service' so how come it is started/reached way before bluetooth.service?
The system’s copy of unit files are generally kept in the /lib/systemd/system directory. When software installs unit files on the system, this is the location where they are placed by default.
If you wish to modify the way that a unit functions or create your own, the best location to do so is within the /etc/systemd/system directory. Unit files found in this directory location take precedence over any of the other locations on the filesystem.
Wants should be in the [Unit] section not in the [Install] section.
[Install] section is optional and is used to define the behaviour of a unit if it is enabled or disabled. I have only every put WantedBy=multi-user.target in this section. The multi-user.target tells systemd (as I understand it) that it is needed for “normal operation”.
I was trying to set up a Twonky Server on Ubuntu. The server works fine, but I could not get systemd to autostart the server (using a service file I created at /etc/systemd/system/twonkyserver.service). Sometimes I got the cryptic error message that some PID-file (/var/run/mediaserver.pid) is not accessible, the exit code of the service is 13, which apparently is a EACCES Permission denied error . The service runs as root.
I finally managed to fix the problem by setting PIDFile in the twonkyserver.service file to /var/run/mediaserver.pid. For reference, find the service file below:
[Unit]
Description=Twonky Server Service
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/twonky/twonky.sh start
ExecStop=/usr/local/twonky/twonky.sh stop
ExecReload=/usr/local/twonky/twonky.sh reload
ExecRestart=/usr/local/twonky/twonky.sh restart
PIDFile=/var/run/mediaserver.pid
Restart=on-failure
[Install]
WantedBy=multi-user.target
As described above, the below service file auto-starts the Twonky Server on boot. Simply create it using vim /etc/systemd/system/twonkyserver.service. This assumses that you have installed the Twonky Server to usr/local/twonky. The shell-file twonky.sh already provides a nice interface to the service file (twonky.sh start|stop|reload|restart, also see twonky.sh -h).
[Unit]
Description=Twonky Server Service
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/twonky/twonky.sh start
ExecStop=/usr/local/twonky/twonky.sh stop
ExecReload=/usr/local/twonky/twonky.sh reload
ExecRestart=/usr/local/twonky/twonky.sh restart
PIDFile=/var/run/mediaserver.pid
Restart=on-failure
[Install]
WantedBy=multi-user.target
I would slightly amend the start and stop commands from twonky.sh and put them directly into the twonky.service file for systemd:
[Unit]
Description=Twonky Server Service
After=network.target
[Service]
Type=simple
#Systemd will ensure RuntimeDirectory for the PID file is created under /var/run
RuntimeDirectory=twonky
PIDFile=/var/run/twonky/mediaserver.pid
# use the -mspid argument for twonkystarter to put the pid file in the right place
ExecStart=/usr/local/twonky/twonkystarter -mspid /var/run/twonky/mediaserver.pid -inifile /usr/local/twonky/twonkyserver.ini -logfile /usr/local/twonky/twonky.log -appdata /usr/local/twonky
ExecStop=kill -s TERM $MAINPID
ExecStopPost=-killall -s TERM twonkystarter
ExecStopPost=-killall -s TERM twonky
# Twonky 8.5.1 doesn't reload, it stops instead (on arm at least)
# ExecReload=kill -s HUP $MAINPID
Restart=on-failure
[Install]
WantedBy=multi-user.target
You need to be sure the paths in the ExecStart command match where you unpacked twonky, and also where you want the .pid file, configuration, logfile and runtime appdataunless you are happy with their default locations.
After putting that all into/etc/systemd/system/twonky.server, run
sudo systemctl daemon-reload
sudo systemctl start twonky
sudo systemctl enable twonky
I have a systemd service that starts a Node app on boot. The Node app uses child_process.spawnSync to launch a shell script that edits /etc/wpa_supplicant/wpa_cli-actions.sh using sed.
The wpa_cli-actions.sh file is edited correctly if I launch the Node app manually from the command line, but is not edited correctly when the app is launched by systemd. My systemd service file is based on another one that launches a similar service, so I'm not sure what I'm doing wrong. I haven't seen any errors related to this in the journalctl output. Below is my service file.
[Unit]
Description=The Edison status and configuration service
After=mdns.service
[Service]
ExecStart=/bin/su root -c 'node /usr/lib/config-server/app.js'
Restart=always
RestartSec=10s
StandardOutput=journal
StandardError=journal
SyslogIdentifier=edison-config
PrivateTmp=no
Environment=NODE_ENV=production
User=root
Group=root
[Install]
WantedBy=default.target
Try The following, And root is enabled by default if you don't specify User or Group, replace entire <path to node> with your path to node, it can be found with which node.
[Unit]
Description=The Edison status and configuration service
After=mdns.service
[Service]
ExecStart=<path to node> /usr/lib/config-server/app.js
WorkingDirectory=/usr/lib/config-server
Restart=always
RestartSec=10s
StandardOutput=journal
StandardError=journal
SyslogIdentifier=edison-config
PrivateTmp=no
Environment=NODE_ENV=production
[Install]
WantedBy=default.target