I'm trying to run a trivial script at bootup on my debian testing machine. I followed a few guides, but the services do not start. Can someone show me what I'm doing wrong? I'd like to understand systemd before I start whining about it on the internet.
I created /etc/systemd/system/startup-scripts.service (sometimes here, sometimes as a symlinks to /lib/systemd/system/my-file.service) and wrote
[Unit]
Description=Sync date at boot up
[Service]
ExecStart=/usr/bin/startup-script.sh
Type=simple
[Install]
WantedBy=multi-user.target
then ran
sudo systemctl enable startup-scripts.service
I also filed out /usr/bin/startup-script.sh, made it executable, and ran it. As far as I could tell the script would run, but my reboots have been fruitless.
I'm guessing the answer will involve journalctl. Not really sure what I'm looking at here. I also wouldn't be surprised if multi-user is the wrong target. It was the most reasonable looking one, but I'm not really confident about what it's for.
Related
telnet is necessary in order to maintain compatibility with older software in this case. I'm working with the Yocto Rocko 2.4.2 distribution. when I try to telnet to the board I'm getting the oh so detailed message "connection refused".
Using the method here and the options here I modified the busybox configuration per suggestion. When the board is booted up and logged in, if you execute: telnet, it spits out usage info and a quick directory check shows that telnet is installed to /usr/bin/telnet. My guess is that the telnet client is installed but the telnet server is not running?
I need to get telnetd to start manually at least so I know it will work with an init script in place. The second reference link there suggests that 'telnetd will not be started automatically though...' and that there will need to be an init script. How can I start telnetd manually for testing?
systemctl enable telnetd
returns: Unit telnetd.service could not be found
UPDATE
telnetd in located in /usr/sbin/telnetd. I was able to manually start the telnetd service for testing from there. After manually starting the service telnet login now works. looking into writing a systemd init script to auto start the telnetd service, so I suppose this issue is closed. unless anyone would like to offer up detailed telnet busybox configuration and setup steps as an answer to 'How to configure telnet service for yocto image'
update
Perhaps there is something more? I created a unit file that looks like this:
[Unit]
Description=auto start telnetd
[Service]
ExecStart=/usr/sbin/telnetd
[Install]
WantedBy=multi-user.target
on reboot, systemd indicates the process executed and succeeded:
systemctl status telnetd
.
.
.
Process: 466 ExecStart=/usr/sbin/telnetd (code=exited, status=0/SUCCESS)
.
.
.
The service is not running however. netstat -l does not list it and telnet login fails. Something I'm missing?
last update...i think
so following this post, I managed to get telnet.socket service to startup on reboot.
systemctl status telnet.socket
shows that it is running and listening on 23. Now however, when I try to remote in with telnet I'm getting
Connection closed by foreign host
Everything I've read so far has been talking about xinetd service (which I do not have...). What is confusing is that, if I just navigate to /usr/sbin/ and execute telnetd, the server is up and running and I can telnet into the board, so I do not believe I'm missing any utilities or services (like the above mentioned xinetd), but something is still not being configured correctly. any ideas?
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
I am attempting to launch a mono program with systemctl. My .service looks like this:
[Unit]
Description=Starts results sender
After=network.target systemd.mount
[Service]
Type=forking
ExecStart=/usr/bin/mono /home/ubuntu/CameraInfoSender/CameraInfoSender.exe
,but it immediately exits with (code=exited, status=0/SUCCESS), before doing any work. This command works when launched manually. Adding Retart=on-success doesn't help, nor does WantedBy. Any help will be appreciated.
Check that you are using the appropriate Type=. The Type= options are documented in man systemd.service.
Also check the answer the FAQ of why things run in the shell but not via systemd.
I used to run my pyramid server as a daemon with the pserve --daemon command.
Given that it's deprecated, I'm looking for the best replacement. This link recommends to run it with screen or tmux, but it seems too heavy to just run a web server. Another idea would be to launch it with setsid.
What would be a good way to run it ?
Create a service file in /etc/systemd/system. Here a example (pyramid.service):
[Unit]
Description=pyramid_development
After=network.target
[Service]
# your Working dir
WorkingDirectory=/srv/www/webgis/htdocs/app
# your pserve path with ini
ExecStart=/srv/www/app/env/bin/pserve /srv/www/app/development.ini
[Install]
WantedBy=multi-user.target
Enable the service:
systemctl enable pyramid.service
Start/Stop/Restart the service with:
systemctl start pyramid.service
systemctl restart pyramid.service
systemctl stop pyramid.service
The simplest option is to install supervisord and setup a conf file for the service. The program would just be env/bin/pserve production.ini. There are countless examples online of how to do this.
The best option is to integrate with your system's process manager (systemd usually, but maybe also upstart or sysvinit or openrc). It is very easy to write a systemd unit file for starting pserve and then it will be started/stopped along with the rest of your system. Log files are even handled automatically in these cases.
I am using Ubuntu 14.04 LTS and I have installed MongoDB 3.2.1. I had various problems with it that I fixed by either finding help from the internet (thanks Google) or by uninstalling and re-installing MongoDb.
One persistent problem that I cannot fix, unless I re-install, is by running mongod on the terminal. Currently my mongodb installation is working properly. With sudo service mongod start I start mongodb (I commented out start on xxxx line at /etc/init/mongod.conf so it doesn't auto start.) and with sudo service mongod stop I can stop it normally atm. And it correctly uses /var/lib/mongodb path for saving my collections.
If however after I stop mongodb with sudo service mongod stop I hit, on the terminal, mongod then mongodb breaks. I have gotten all kinds of errors like
Unusable mongod.lock. I have gotten around it, in a previous install, by doing sudo mongod but that was not a proper solution.
/data/db folder not found !!. Why look for it in the first place? The /etc/mongod.conf specifies the dbpath /var/lib/mongodb which is also the default when mongodb gets installed !!?? I have gotten around it as well with the mongod --dbpath /var/lib/mongodb option.
I think there was one more error that I don't remember but I also fixed/gotten_around it by finding solutions online.
I know that by re-installing and by never running mongod I can - for now? - not face those problems again (which looks a much better solution that the "workarounds" I did whenever those problems arose. I am wondering however what it is that is going wrong when I type mongod instead of sudo service mongod start ?!
In case somebody tries to replicate the problem know that I ve done only two modifications on my system after installing:
Commenting out the start on xxxx line at /etc/init/mongod.conf
Disabling transparent hugepages as described on the answer here.
I don't think anyone of those should interfere with my installation.
Can anyone help me understand what is going on? Aren't those commands supposed to do the same thing??
Thanks for your help.
Ok, I will try to answer.
First, unless you know what you are doing, you should not start mongod manually.
In general (a bit simplified), calling [sudo] service mongod start, you instruct the system to read the according file in /etc/init and start the executable according to the configuration described in said file.
When you started mongod by hand, however, you actually called the mongod binary, the server software itself – while the name is the same as the service, the two commands have few things in common. The binary does not use the /etc/mongod.conf by default, falling back to its default values for the various settings. Actually, you can see that the config file is explicitly defined in the init script. This is why mongod tried to find /data/db.
You can find said binary by issuing
which mongod
Regarding the lock file: When mongod is started by the system, user root actually assumes the effective user id of mongod (or mongodb I don't know for Ubuntu of the top of my head). When you tried to start it from your user id, you do not have the privileges to overwrite the lock file. When you used sudo mongod afterwards, you assumed the effective user id of root which on the other hand is allowed to overwrite said file. However, mongod will the run as root which is a security no-no.
An init script defines which environment to use, which user to run under and a lot of other stuff. Unless you really know what you are doing, you should not even fiddle with them, much less skip it.
And now, with the finger up
sudo is not the UNIX way of saying "I mean it!"
It has security implications, and you should be very aware of those implications before using it – aka read the man pages of every command you issue before you use it until you have at least a fact based idea of what the command is doing.
And again: unless you really know (as opposed to assume) what you are doing, do not fiddle with the system configuration.