Is it possible to run a systemd session below the user session with unit files in a subdirectory and not installed in ~/.config/systemd? I'm developing a system consisting of different services (implemented in C++), some of which depend on each other. Currently, they're run from a bash script and all write to stdout. I would love to be able to start them from the build directory, e.g.
# enter build directory
cd /path/to/project/build
# start services
systemd --root ./systemd-units &
# check status of services
systemctl --root ./systemd-units status
# check log output of services
journalctl --root ./systemd-units
Unfortunately no such option exists and I couldn't find any alternative. I don't want to use docker because it makes debugging unnecessarily difficult.
Is there a way to do what I want with systemd? I looked into other systems and runit seems to be able to do what I want but is unlikely to be used in the final product.
It sounds like you may want to use the link feature of systemctl, so you can link units that are not the search path into the search path.
Related
Having to manage a few production servers over different Linux distributions, I find it hard to remember the exact name of the service to restart/stop.
Is there anyway systematic way to determine the name of a running service, and subsequently being able to run
service <service name> status/stop/reload/start
commands?
Generally, programs that execute tasks in the background are normally known as “services” and “daemons”.
We can use "service" or "systemctl" to manage these servcies.
Example:
-service service-name start
-systemctl start service-name
Mostly custom service files will be at "/etc/init.d/" directory and custom systemd files will be at "/etc/systemd/system/" directory
for centos 7 use
systemctl list-unit-files
In opensuse docker container, cronjob is not working. When I try systemctl command getting this error: Failed to et D-bus: Unknown error -1 . I have tried many blogs and stackoverflow questions everywhere It was advised that basic architecture of Docker image should be redesigned.
What exactly needs to be done here is not mentioned. Kindly help, I am stuck on this issue.
To a first approximation, commands like systemctl, initctl, service, or start just don't work in Docker and you should find a different way to do what you're attempting.
Stylewise, the standard way to use a Docker container is to launch some sort of service in the foreground. As one specific example, the standard Redis image doesn't go through any sort of init script; it just runs
CMD ["redis-server"]
In most Docker images it's unusual to even so much as launch a background process (with the shell & operator). It's not usually necessary and in Dockerfiles the interaction with the RUN directive has confused some people.
In the specific case of systemctl, it requires an extremely heavyweight init system that is not just a process manager but also wants to monitor and manage kernel-level parameters, includes a logging system, runs an inter-process message bus, and some other functionality. You can't run systemd under Docker without the container being --privileged, which gives the container the ability to "escape" on to the host system in some unfortunate ways.
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'm deploying a node web application as an upstart service using grunt and monitoring it using monit. However:
My upstart and monit configuration duplicate each other a little bit
Upstart doesn't do variable expansion inside env stanzas
I can't find a way to configure monit dynamically (ala upstart .override files)
My question
This means I'm looking for a grunt plugin or other tool that I can use to generate the uptstart .conf and monit conf.d/ files. Can you please help me find one (or suggest a better way of robustly running my node web app)?
A rather crude solution?
To be honest an underscore template of the upstart and monit files would probably be sufficient, and that's what I'll wrap up into a grunt plugin if there isn't a ready-made solution, but this feels like a problem that other people must have run into as well so I imagine there's a solution out there, I just can't find it.
Detail
A bit more detail to illustrate the three problems. My upstart conf file looks like this:
setuid node
setgid node
# ...
script
mkdir -p /home/node/.my-app
echo $$ > /home/node/.my-app/upstart.pid
/usr/local/bin/node /var/node/my-app/server.js >> /var/node/my-app/logs/console.log 2>&1
end script
# ...
And my monit configuration looks like this:
check process node with pidfile /home/node/.my-app/upstart.pid
start program = "/sbin/start my-app" with timeout 60 seconds
stop program = "/sbin/stop my-app"
if failed host localhost port 17394 protocol http
and request "/monit.html"
then restart
if 3 restarts within 5 cycles then timeout
As you can see, the PID file path and config directory is duplicated across the two (problem 1) and I'd love to parameterise the host, port and request URL in the monit file (problem 3).
For problem 2 (no variable expansion in upstart's env stanza, bug report here) there are a couple of workarounds that work for variables used inside *script blocks, which are interpreted as bash scripts, but they don't seem to work in the conf file itself. I think this makes it impossible to specify the user id the app should run as in a configuration file?
Those techniques I just mentioned:
Method 1: Don't use env - echo the variables in the pre-script to a file and then source it later
Method 2: Duplicate the variable expansion in all the script bodies where it is needed
Method 3: Store the variables in a file and cat them in using command substitution
...or suggest a better way of robustly running my node web app
Use PM2 by Unitech instead.
I run all my node apps using PM2. It works perfectly and is easy to configure. It has built-in functionality for autogenerating of startup script. It gives you logging, monitoring and easy maintenance.
Here is a good article showing off the highlights.
Install
npm install -g pm2
Start app
pm2 start app.js
Show running apps
pm2 list
Make a startup script
pm2 startup [ubuntu|centos|systemd]
More details in the readme on their github page
Can we hook to similar start,stop etc events. Do we have to write them as shell scripts? I know of mono port of .NET.
You are looking for something called an 'init script'. These are scripts that allow you to start or stop a service with a single command, like so:
service httpd restart
service httpd stop
service httpd start
Some Linux distributions do not include the service command, in which case you access init scripts directly by their location, /etc/init.d, like so.
/etc/init.d/mysqld restart
You can program your init script to accept whatever parameters you want (start, stop, restart, etc). Some basic tutorials on writing init scripts to get you started can be found at the following web pages:
http://www.cyberciti.biz/tips/linux-write-sys-v-init-script-to-start-stop-service.html
http://www.linuxquestions.org/questions/programming-9/how-to-write-init-script-376302/
Many times an init script is unnecessary, and you can just go with the simpler option of executing your program in the background and killing it manually. Running an executable on Linux in the background can be done like so:
./some_prog arg1 arg2 &
And killing it is done like this:
kill `pgrep some_prog`
If you are fairly new to Linux, that latter option might be a much easier way to go until you get a handle on init scripts and the general Linux service ecosystem.