I wrote a program (node js, on Raspberry Pi) that I can start manually, but not as a systemd service:
pi#blueberry ~ $ systemd --version
systemd 215
+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP -APPARMOR
pi#blueberry ~ $ sudo systemctl daemon-reload
pi#blueberry ~ $ sudo systemctl start /etc/systemd/system/rfxtrx.service
Failed to start etc-systemd-system-rfxtrx.service.mount: Unit etc-systemd-system-rfxtrx.service.mount failed to load: No such file or directory.
pi#blueberry ~ $
The error message complains that there is no rfxtrx.service.mount unit. Correct. Should there be such unit? The most common suggestion is to daemon-reload; this doid not help. Or as per https://github.com/systemd/systemd/issues/5375 this could be a bug in systemd that was fixed but only in a later systemd version than the one in raspbian (raspbian has version 215).
Is there any other solution than trying to update to a version not supported by the raspbian maintainers?
Well the first problem here is that you're running to start the service name rfxtrx.service however systemd is expecting etc-systemd-system-rfxtrx.service.mount.
If you are trying to have a systemd mount configuration then your file name should follow the following rule:
Mount units must be named after the mount point directories they
control. Example: the mount point /home/lennart must be configured in
a unit file home-lennart.mount.
So if you were wanting to create a mount point at say /dir/to/rfxtrx then the systemd mount file needs to be named dir-to-rfxtrx.mount, and it's recommended that it sits in either /usr/lib/systemd/system/ or /etc/systemd/system/ with the latter directory taking precedence.
If you just wanted to have a service file then enable the unit systemctl enable rfxtrx.service. systemctl daemon-reload is used when the unit has already been registered with systemd and requires a reload.
You can check if the service exists with systemd by using the command systemctl list-units or systemctl status rfxtrx.service.
The error you have is that you're doing sudo systemctl start /etc/systemd/system/rfxtrx.service instead of sudo systemctl start rfxtrx.service.
Related
I've created the following systemd unit in the cloud-init file:
- path: /etc/systemd/system/multi-user.target.wants/docker-compose.service
owner: root:root
permissions: '0755'
content: |
[Unit]
Description=Docker Compose Boot Up
Requires=docker.service
After=docker.service
[Service]
Type=simple
ExecStart=/usr/local/bin/docker-compose -f /opt/data/docker-compose.yml up -d
Restart=always
RestartSec=30
[Install]
WantedBy=multi-user.target
When I try to run
sudo systemctl enable docker-compose.service
to create the symlink I get this:
Failed to execute operation: No such file or directory
However I'm sure that the file is under /etc/systemd/system/multi-user.target.wants
I had the same need, but I was working from a recipe that said to create /etc/systemd/system/unit.service and then do systemctl enable --now unit.
So I created the unit file with write_files and did the reload and enable in a text/x-shellscript part and that worked fine. (User scripts run last and in order, while I don't think there are guarantees about when the write_files key in the user-data is processed. I found out the hard way that it's before the user key so you can't set ownership to users that cloud-init creates).
I think runcmd entries are converted to user scripts and run in list order (either before or after the other user scripts), so if you don't like x-shellscript parts you can do the reload and enable that way. /var/log/cloud-init.log is where I check the order, there is probably a config file too.
Full disclosure: I forgot the systemctl daemon-reload command but it still worked. Actually there is a caveat against systemd manipulations from cloud-init because it's running under systemd itself and some systemd commands may wait for cloud-init to finish -- deadlock!
After unit file creation but before any manipulations with it systemd should be notified about the changes:
systemctl daemon-reload
So cloud-init YAML block creating docker-compose.service file should be followed by:
runcmd:
- systemctl daemon-reload
Check that every file involved is present and valid:
ls -l /etc/systemd/system/multi-user.target.wants/docker-compose.service
ls -l /usr/local/bin/docker-compose
ls -l /opt/data/docker-compose.yml
systemd-analyze verify /etc/systemd/system/multi-user.target.wants/docker-compose.service
Also consider the timing. Even if the files exist once they are fully booted, would /etc/systemd/system/multi-user.target.wants/ exist when cloud-init runs?
I need to copy a bunch of files into some folder every time the httpd service restarts
e.g.:
yes | cp ./dynamic/*.file /folder/inside/my/webapp
is there a way to run some additional commands when the httpd is restarted?
According to this: https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units
You can edit the httpd service file with:
sudo systemctl edit --full httpd.service
You should be able to add more directives to the service unit, such as running your additional commands.
I want to set target to service in CentOS7 (Systemd).
I want to know following.
How to set target to service.
How to show target of service.
In other words, I want to know substitution for following commands.
$ sudo chkconfig --level=2345 mysql on (<- set runlevel)
$ chkconfig --list mysql (<- show runlevel)
I understood that "runlevel" in CentOS6 changed "target" in CentOS7and I should use "systemctl" command.
But problems were not solved.
I heard that following command is replacement for "chkconfig --list"
, but I can't check target and can't set target.
systemctl list-unit-files
Setting the target is done in the unit file for the service. For example:
[Install]
WantedBy=multi-user.target
Then you run systemctl enable $service_name to create a symlink which enables the service to start as part of a particular target. You could also create the symlinks manually. The enable command will print out the paths of the symlinks it's creating.
I think systemctl --reverse list-dependencies $service is the way to find what services and targets depend on a specific services to boot.
I'm starting to work with docker to automate envorinments, then I'm trying to build a simple LAMP so the Dockerfile is the following:
FROM centos:7
ENV container=docker
RUN yum -y swap -- remove systemd-container systemd-container-libs -- install systemd systemd-libs
RUN yum -y update; yum clean all; \
(cd /lib/systemd/system/sysinit.target.wants/; for i in *; do [ $i == systemd-tmpfiles-setup.service ] || rm -f $i; done); \
rm -f /lib/systemd/system/multi-user.target.wants/*;\
rm -f /etc/systemd/system/*.wants/*;\
rm -f /lib/systemd/system/local-fs.target.wants/*; \
rm -f /lib/systemd/system/sockets.target.wants/*udev*; \
rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \
rm -f /lib/systemd/system/basic.target.wants/*;\
rm -f /lib/systemd/system/anaconda.target.wants/*;
VOLUME [ "/sys/fs/cgroup" ]
RUN yum -y update && yum clean all
RUN yum -y install firewalld httpd mariadb-server mariadb php php-mysql php-gd php-pear php-xml php-bcmath php-mbstring php-mcrypt php-php-gettext
#Enable services
RUN systemctl enable httpd.service
RUN systemctl enable mariadb.service
#start services
RUN systemctl start httpd.service
RUN systemctl start mariadb.service
#Open firewall ports
RUN firewall-cmd --permanent --add-service=http
RUN firewall-cmd --permanent --add-service=https
RUN firewall-cmd --reload
EXPOSE 80
CMD ["/usr/sbin/init"]
so when I build the image
docker build -t myimage .
Then when I run the code I get the following mistake:
The command '/bin/sh -c systemctl start httpd.service' returned a non-zero code: 1
When I enter to interactive mode(jumping the commands after RUN systemctl start httpd.service and rebuidling the image):
docker run -t -i myimage /bin/bash
And after try to start manually the service httpd I get the following mistake:
Failed to get D-Bus connection: No connection to service manager.
so, I don't know what am I doing wrong?
First of all, welcome to Docker! :-) Loads of Docker tutorials and docs are written around Ubuntu containers, but I like Centos too.
Ok, there are a couple of things to talk about here:
You're running up against a known issue with systemd-based Docker containers where they seem to need extra privileges to run, and even then lots of extra config is required to get them working. The Red Hat team are experimenting with some fixes (mentioned in comments) but not sure where that's at.
If you wish to try getting it working, these are the best instructions I've found, but I've played with this several times in the last couple of weeks and not got it working yet.
What people might say is "the real issue" here is that a Docker container should not be thought of as a "mini Virtual Machine". Docker is designed to run one "root" process per container, and the container system makes it easy to compose multiple containers together - they are small on disk, light on memory usage and easy to network together.
Here's a blog post from Docker which gives some background on this. There's also the "Docker Fundamentals" docs on Dockerizing applications and Working with containers.
So arguably the best way to proceed with the setup you're attempting to create here (though it might sound more complicated at the beginning) is to break your "stack" up into the services you need, and then use a tool like docker-compose (introduction, documentation) to create single-purpose Docker containers as required.
In your case above, you have two services, a web server and a database server. Therefore two Docker containers should work well, connected together by the database network connection. Here are some examples:
example with Symfony app, nginx and MariaDB
example with MariaDB + NodeJS
If you run one service per Docker container, you don't need to use systemd to manage them, as the Docker daemon manages each container sort of like it is a Unix process. When the process dies, the Docker container dies, and this is important because the Docker server monitors containers and can restart them automatically, or notify you.
This looks more like a perfect example where my docker-systemctl-replacement would fit into. It can easily interpret "systemctl start httpd.service" without an active SystemD around. I have done the same for some database services but not specifically the mariadb.service - may be you could give it a try.
I've installed the last stable version of Debian (Jessie) and /etc/inittab doesn't exist. I have read the new init system is called Sysv.
I need to launch a service with parameter, I used to add a line in inittab like
u1:23:respawn:/etc/init.d/my_service foreground
I'm trying to add this one with sysvrc-conf -p but I don't know how...
How can I do that without inittab?
Thank you so much.
Found this question by google, maybe someone else finds this usefull: The new init system for Debian Jessie is systemd. The old way in Debian Wheezy was Sysv with /etc/inittab.
To create a respawn service with systemd just create a file in /etc/systemd/system/ i.e. mplayer2.service
[Unit]
Desription=mplayer with systemd, respawn
After=network.target
[Service]
ExecStart=/usr/bin/mplayer -nolirc -ao alsa -vo null -really-quiet http://stream.sunshine-live.de/hq/mp3-128/Facebook-og-audio-tag/
Restart=always
[Install]
WantedBy=multi-user.target
and activate it
systemctl enable mplayer2.service
reboot or start it manually
systemctl daemon-reload
systemctl start mplayer2.service
If you reboot or kill the process, it will be restarted automatically some seconds later.