Cant enable service with systemctl - raspberry-pi

I made this service:
#!/bin/bash
node ../../home/NodeServer/server.js
All it should do is start the server on bootup, so i wanted to do
sudo systemctl enable startServer.service
But I got this error:
startServer.sh.service is not a native service, redirecting to systemd-sysv-insall.
Executing: /lib/systemd/systemd-sysv-install enable startServer.sh
update-rc.d: error: startServer.sh Default-Start contains no runlevels, aborting.
When i try to do
sudo systemctl start startServer.service
it works like intended.

I had the same problem. I solve it typing again the file because it seems that there was a strange character that was broken the parser. Hope this helps!

You want to execute a script, which is not the same as a service.
You can make a file called startServer.service and write the following into it:
[Unit]
Description=Start server that does a thing
[Service]
ExecStart=node /home/NodeServer/server.js
If you want to enable the service, do the following:
sudo ln -s /home/NodeServer/startServer.service /etc/systemd/system/
and now you should be able to start the service.

Related

Can't see my dbus object when program run from systemctl service

I have a cpp application which broadcasts an object and its methods on the dbus. I try to run this program at startup with the following service file:
[Unit]
Description=Running dbus program
After=network.target
[Service]
Type=simple
ExecStart=/home/my_name/Documents/dbus/build/my_app
StandardOutput=console+journal
StandardError=console+journal
[Install]
WantedBy=multi-user.target
After reloading:
systemctl daemon-reload
and running it:
sudo systemctl start my_service.service
I got no error in the journal, but I cant see anything on the dbus (running d-feet, and browsing for my object, I cant find anything)
Running the exact same ExecStart:
/home/my_name/Documents/dbus/build/my_app
in the console works fine.
What am I missing? Thanks!
As you want your service to run on the session bus you will need to use:
sudo systemctl --user start my_service.service
Putting the file into /etc/systemd/user/ location will make it available to all users still.

Logstash service failure CentOS7 - Some newbie questions

I am really struggling to launch logstash as a service on CentOS 7. Since I cannot figure out what or where to set the
-DJava.io.tmpdir= variable (which apparently would solve my issue), I am trying to create a little script to launch the logstash command line on boot.
The following line works manually for me:
sudo /usr/share/logstash/bin/logstash -f /etc/logstash/conf.d
That successfully loads and opens port 5000.
So I am trying to create a boot time script to run that line and start logstash.
My problem is that I think I need the sudo command as it fails to run without it. Does anyone know how I can get this to work?
I have the following files /etc/systemd/system/mylogstash.service:
[Unit]
After=network.target
[Service]
ExecStart=/usr/local/bin/disk-space-check.sh
[Install]
WantedBy=default.target
and also /usr/local/bin/mylogstashstart.sh:
#!/bin/bash
/usr/share/logstash/bin/logstash -f /etc/logstash/conf.d
To make the script executable I have done:
chmod 744 /usr/local/bin/mylogstash.sh
and
chmod 664 /etc/systemd/system/mylogstash.service
It fails to execute as there are insufficient permissions. How do I replicate the Sudo in the script without storing a password and do I even need to?
Can anyone tell me where I have gone wrong please? I'm getting pretty desperate, and no-one likes to see a man desperate...
Thanks,
QR

systemctl enable works but systemctl --user enable does not

I have a DO droplet running Ubuntu 16.04.1x64 and I'm trying to run IPFS as a systemd service. I've gone ahead and created a user "connor" and installed IPFS following the instructions here. I'm storing the service as "ipfs.service" in ~/.config/systemd/user/ipfs.service which looks like this:
[Unit]
Description=IPFS Daemon
[Service]
Type=simple
ExecStart=/usr/local/bin/ipfs daemon
ExecStop=/usr/bin/pkill ipfs
Restart=always
User=Connor
[Install]
WantedBy=default.target
What's odd is that if I run systemctl --user start ipfs it starts up just fine. However, running systemctl --user daemon-reload and then
systemctl --user enable ipfs I get the error:
Failed to execute operation: No such file or directory
However, if I run systemctl enable /home/connor/.config/systemd/user/ipfs.service -f it runs just fine. I can reboot and run IPFS commands just fine. I'd like to run it as a user though, and would also like to understand what I'm doing wrong.
Please, check that you are executing the commands with connor user, you may run whoami to see the user executing the command. (running the command with sudo changes the user to root)
In addition, I see that the user in the service file is capitalized (Connor instead of connor), this could bring other problems, and it is not needed, as a simple configuration like the one proposed by Arch Linux wiki works for user daemons.
Please find bellow the configuration I used for my ipfs daemon, (without User= and with a different Restart=, since Restart=always gave me problems while starting the daemon):
[Unit]
Description=IPFS daemon
After=network.target
[Service]
ExecStart=/usr/local/bin/ipfs daemon
Restart=on-failure
[Install]
WantedBy=default.target

How to set target (runlevel) to service in CentOS7 (Systemd)?

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.

Docker Lamp Centos7: '/bin/sh -c systemctl start httpd.service' returned a non-zero code: 1

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.