I'm new to the concept of systemd unit files in Centos 7 but need to start up the MATLAB license manager at boot. MATLAB doesn't offer a specific solution on how to do this, and the following seems to work but asks for a password when typing systemctl start license-manager and systemctl stop license-manager. Is that expected?
Note this does need to run as a specific user and not as root.
Here is my /etc/systemd/system/license-manager.servicefile:
[Unit]
Description=MATLAB FlexLM license manager
[Service]
Type=forking
ExecStart=/usr/local/MATLAB/R2016a/etc/lmstart
ExecStop=/usr/local/MATLAB/R2016a/etc/lmdown
KillMode=none
Restart=on-failure
RestartSec=90
User=lmlicenseuser
[Install]
WantedBy=multi-user.target
You can try Crontab
bash$ crontab -e
then add the following line
#reboot /usr/local/MATLAB/R201Xx/etc/lmstart
This should resolve your issue.
Traditionally it is always expected for non-root users to be asked for a password when running commands as other users, yes.
However, because you have specified that it is a dependency of multi-user.target, it should always be started automatically whenever you reboot in future, so you shouldn't need to enter the password in future.
If for some reason you do still need to control it manually in future, you can use sudo and edit /etc/sudoers to allow those two particular commands to be run without a password, using NOPASSWD.
Related
I'd like to run syncthing as a daemon, trying to follow this hint here from the syncthing manual.
I'm running on Fedora 25 and syncthing 0.14.24.
The executable is pointed to via a symlink in /usr/bin/syncthing which can be executed by any user (tested this successfully).
To enable the service, I'm typing (myuser is replaced with my actual username in all of the below):
sudo systemctl enable sycnthing#myuser.service
Which returns:
Failed to lookup unit file state: Invalid argument
I don't understand what the error message means. How could I get to run syncthing as a daemon?
syncthing#myuser.service:
[Unit]
Description=Syncthing - Open Source Continuous File Synchronization for %I
Documentation=man:syncthing(1)
After=network.target
Wants=syncthing-inotify#myuser.service # I also commented this line out; didn't have an effect
[Service]
User=%i
ExecStart=/usr/bin/syncthing -no-browser -no-restart -logflags=0
Restart=on-failure
SuccessExitStatus=3 4
RestartForceExitStatus=3 4
[Install]
WantedBy=multi-user.target
I think myuser should be substituted for your actual username.
Arch wiki has a pretty good article:
System service
Running Syncthing as a system service ensures that it is running at startup even if the user has no active session, it is intended to be used on a server.
Enable and start the syncthing#myuser.service where myuser is the actual name of your user.
Credit: https://wiki.archlinux.org/index.php/Syncthing
I have a script which normally i run using ./myscript.sh(contain java run command) on linux. Now i want to make it as a service so it run automatically after machine restart and if i want to stop and start again simply find the process and kill and start it again from command line.
What i find with quick google search is to place the script in /etc/init.d directory but confusing with one thing that command inside this script using other certificate files which i normally place on same level where this script is place. Do i need to move all others file along with this script under /etc/init.d or is there any better way that i simply mention the path of this script in some file?
You need to write systemd service file.
Simplest script looks like this:
[Unit]
Description=Virtual Distributed Ethernet
[Service]
ExecStart=/usr/bin/YOUR_SCRIPT
[Install]
WantedBy=multi-user.target
Also you need: systemctl daemon-reload after creating new service.
I'm trying to set up systemd to start some programs when I log in. I'm doing this by putting files in e.g. ~/.config/systemd/user/some.service. This has worked for my emacs server service, which looks like this:
[Unit]
Description=Emacs: the extensible, self-documenting text editor
[Service]
Type=forking
ExecStart=/usr/bin/emacs --daemon
ExecStop=/usr/bin/emacsclient --eval "(kill-emacs)"
Environment=SSH_AUTH_SOCK=%t/keyring/ssh
Restart=always
[Install]
WantedBy=default.target
This starts a background process and allows me to connect to the emacs service with emacsclient
What's not working is my terminator service:
[Unit]
Description=The only terminal emulator that seems to be somewhat decent
After=multi-user.target
[Service]
ExecStart=/usr/bin/terminator
Restart=always
Environment=DISPLAY=:0
[Install]
WantedBy=default.target
With this code in ~/.config/systemd/user/terminator.service I can start terminator on the command-line with systemctl --user start terminator, but I can't get terminator to start automatically on (graphical) login. I've tried messing around with the WantedBy and After lines, switching between to graphical.target, default.target and multi-user.target, but it's really just guess work and hasn't helped.
Any ideas?
your terminator service file looks okay to me.
check below things
1. just check "default.target" file, is this below line present in that file
After=multi-user.target
2. if you write "WantedBy=default.target" then you need to create a soft link of terminator.service file inside "default.target.wants/" directory.
if this above two are correct, it should get start.
If still doesn't work, please remove "After=multi-user.target" this line, and change Wantedby as "WantedBy=graphical.target".
let me know the status of service after login
systemctl status terminator.service
Systemd is not the right tool for this task because it doesn't know when you have finished logging in in a desktop environment and it's possible to launch terminator. Instead, you could put a symlink to terminator's desktop file in your ~/.config/autostart :
ln -s /usr/share/applications/terminator.desktop ~/.config/autostart/
Most desktop interfaces (Gnome, KDE, Unity) will launch it when they start.
I am writing a Daemon and I want to use start-stop-daemon command to do it but, when I use it in the command line I get :
The command could not be located because '/sbin' is not included in the PATH environment variable.
This is most likely caused by the lack of administrative privileges associated with your user account.
start-stop-daemon: command not found
but when i use it with sudo it run perfect but i need it to run in daemon and i think it is not good to use sudo in bash script in daemon something like :
sudo start-stop-daemon --start --background ...
Isn't it? When I deleted sudo from it it gave me command not found. How can i fix it? if it is wrong to use sudo in daemon.
start-stop-daemon can also set the user ID for the daemon process.
That said, you'd generally use start-stop-daemon from a script in /etc/rc.d, which is run with root privileges either from the init system that is being used this week (sysvinit, upstart, systemd, ...) and/or from the service(8) command.
So, if a user should be able to start/stop the service (which is a rather uncommon scenario), you'd use the sudoers file to grant them access to the service command, with the name of your service as a mandatory first argument.
In general though, write your service so it can be simply started at boot or during installation, and used by users as long as it's running. If the user needs to be able to start and stop instances of the service, then your daemon is in the business of managing instances, and the instance manager should be continually running, and users then contact this service via a socket (so users don't need sudo at all, which would make the lives of many administrators who don't install sudo quite a bit easier).
That depends on your settings in '/etc/sudoers'.
If the environment is reset (default),
the following path definition 'secure_path' contains /sbin (excerpt from Ubuntu '/etc/sudoers'):
Defaults env_reset
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Otherwise you need to provide the full program path
/sbin/start-stop-daemon
I have recently completed the Wiki web development tutorial (http://golang.org/doc/articles/wiki/). I had tons of fun and I would like to experiment more with the net/http package.
However, I noticed that when I run the wiki from a console, the wiki takes over the console. If I close the console terminal or stop the process with CTRL+Z then the server stops.
How can I get the server to run in the background? I think the term for that is running in a daemon.
I'm running this on Ubuntu 12.04. Thanks for any help.
Simple / Usable things first
If you want a start script without much effort (i.e. dealing with the process, just having it managed by the system), you could create a systemd service. See Greg's answer for a detailled description on how to do that.
Afterwards you can start the service with
systemctl start myserver
Previously I would have recommended trying xinetd or something similar for finer granuarlity regarding resource and permission management but systemd already covers that.
Using the shell
You could start your process like this:
nohup ./myexecutable &
The & tells the shell to start the command in the background, keeping it in the job list.
On some shells, the job is killed if the parent shell exits using the HANGUP signal.
To prevent this, you can launch your command using the nohup command, which discards the HANGUP signal.
However, this does not work, if the called process reconnects the HANGUP signal.
To be really sure, you need to remove the process from the shell's joblist.
For two well known shells this can be achieved as follows:
bash:
./myexecutable &
disown <pid>
zsh:
./myexecutable &!
Killing your background job
Normally, the shell prints the PID of the process, which then can be killed using the kill command, to stop the server. If your shell does not print the PID, you can get it using
echo $!
directly after execution. This prints the PID of the forked process.
You could use Supervisord to manage your process.
Ubuntu? Use upstart.
Create a file in /etc/init for your job, named your-service-name.conf
start on net-device-up
exec /path/to/file --option
You can use start your-service-name, as well as: stop, restart, status
This will configure your service using systemd, not a comprehensive tutorial but rather a quick jump-start of how this can be set up.
Content of your app.service file
[Unit]
Description=deploy-webhook service
After=network.target
[Service]
ExecStart=/usr/bin/go webhook.go
WorkingDirectory=/etc/deploy-webhook
User=app-svc
Group=app-svc
Restart=always
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=deploy-webhook-service
PrivateTmp=true
Environment=APP_PARAM_1=ParamA
Environment=APP_PARAM_2=ParamB
[Install]
WantedBy=multi-user.target
Starting the Service
sudo systemctl start deploy-webhook.service
Service Status
sudo systemctl status deploy-webhook.service
Logs
journalctl -u deploy-webhook -e
After you press ctrl+z (putting the current task to sleep) you can run the command bg in the terminal (stands for background) to let the latest task continue running in the background.
When you need to, run fg to get back to the task.
To get the same result, you can add to your command & at the end to start it in the background.
To add to Greg's answer:
To run the Go App as a service you need to create a new service unit file.
However, the App needs to know where Go is installed. The easiest way to lookup that location is by running this command:
which go
which gives you an output like this:
/usr/local/go/bin/go
With this piece of information, you can create the systemd service file. Create a file named providus-app.service in the /etc/systemd/system/ using the command below:
sudo touch /etc/systemd/system/providus-app.service
Next open the newly created file:
sudo nano /etc/systemd/system/providus-app.service
Paste the following configuration into your service file:
[Unit]
Description=Providus App Service
After=network.target
[Service]
Type=forking
User=deploy
Group=deploy
ExecStart=/usr/local/go/bin/go run main.go
WorkingDirectory=/home/deploy/providus-app
Restart=always
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=providus-app-service
PrivateTmp=true
[Install]
WantedBy=multi-user.target
When you are finished, save and close the file.
Next, reload the systemd daemon so that it knows about our service file:
sudo systemctl daemon-reload
Start the Providus App service by typing:
sudo systemctl restart providus-app
Double-check that it started without errors by typing:
sudo systemctl status providus-app
And then enable the Providus App service file so that Providus App automatically starts at boot, that is, it can start on its own whenever the server restarts:
sudo systemctl enable providus-app
This creates a multi-user.target symlink in /etc/systemd/system/multi-user.target.wants/providus-app.service for the /etc/systemd/system/providus-app.service file that you created.
To check logs:
sudo journalctl -u providus-app