I am installing mesosphere on ubuntu 16.04 xenial .zookeeper and mesos-master and mesos-slave are running fine ,while starting marathon I am getting this issue .
Required option 'master' not found .I have created folder in /etc/marathon/conf .These are the steps I am following for marathon .
sudo mkdir -p /etc/marathon/conf
sudo cp /etc/mesos-master/hostname /etc/marathon/conf
sudo cp /etc/mesos/zk /etc/marathon/conf/master
sudo cp /etc/marathon/conf/master /etc/marathon/conf/zk
sudo nano /etc/marathon/conf/zk ,edit mesos to marathon in the end .
I am attaching the whole logs here,
Jan 25 14:18:01 master01 cron[859]: (*system*) INSECURE MODE (group/other writable) (/etc/crontab)
Jan 25 14:18:01 master01 cron[859]: (*system*popularity-contest) INSECURE MODE (group/other writable) (/etc/cron.d/popularity-contest)
Jan 25 14:18:01 master01 cron[859]: (*system*php) INSECURE MODE (group/other writable) (/etc/cron.d/php)
Jan 25 14:18:01 master01 cron[859]: (*system*anacron) INSECURE MODE (group/other writable) (/etc/cron.d/anacron)
Jan 25 14:18:29 master01 systemd[1]: marathon.service: Service hold-off time over, scheduling restart.
Jan 25 14:18:29 master01 systemd[1]: Stopped Scheduler for Apache Mesos.
Jan 25 14:18:29 master01 systemd[1]: Starting Scheduler for Apache Mesos...
Jan 25 14:18:29 master01 systemd[1]: Started Scheduler for Apache Mesos.
Jan 25 14:18:29 master01 marathon[29366]: No start hook file found ($HOOK_MARATHON_START). Proceeding with the start script.
Jan 25 14:18:30 master01 marathon[29366]: [scallop] Error: **Required option 'master' not found**
Jan 25 14:18:30 master01 systemd[1]: marathon.service: Main process exited, code=exited, status=1/FAILURE
Jan 25 14:18:30 master01 systemd[1]: marathon.service: Unit entered failed state.
Jan 25 14:18:30 master01 systemd[1]: marathon.service: Failed with result 'exit-code'.
Breaking Changes / Packaging standardized
We now publish more normalized packages that attempt to follow Linux Standard Base Guidelines and use sbt-native-packager to achieve this. As a result of this and the many historic ways of passing options into marathon, we will only read /etc/default/marathon when starting up. This file, like /etc/sysconfig/marathon, has all marathon command line options as "MARATHON_XXX=YYY" which will translate to --xx=yyy. We no longer support /etc/marathon/conf which was a set of files that would get translated into command line arguments. In addition, we no longer assume that if there is no zk/master argument passed in, then both are running on localhost.
Try to keep config in the environment.
cat << EOF > /etc/default/marathon
MARATHON_MASTER=zk://127.0.0.1:2181/mesos
MARATHON_ZK=zk://127.0.0.1:2181/marathon
EOF
Remember to replace 127.0.0.1:2181 with proper Zookeeper location.
I am using Ubuntu 14.04 in my case janisz solution did not work as I needed to add export
cat << EOF > /etc/default/marathon
export MARATHON_MASTER=zk://127.0.0.1:2181/mesos
export MARATHON_ZK=zk://127.0.0.1:2181/marathon
EOF
Related
I configured a minio instance server on the ubuntu 18.04 with the guide from https://www.digitalocean.com/community/tutorials/how-to-set-up-an-object-storage-server-using-minio-on-ubuntu-18-04.
after the installation, the server failed to start with the command "sudo systemctl start minio", the error is saying :
root#iZbp1icuzly3aac0dmjz9aZ:~# sudo systemctl status minio
● minio.service - MinIO
Loaded: loaded (/etc/systemd/system/minio.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2021-12-23 17:11:56 CST; 4s ago
Docs: https://docs.min.io
Process: 9085 ExecStart=/usr/local/bin/minio server $MINIO_OPTS $MINIO_VOLUMES (code=exited, status=1/FAILURE)
Process: 9084 ExecStartPre=/bin/bash -c if [ -z "${MINIO_VOLUMES}" ]; then echo "Variable MINIO_VOLUMES not set in /etc/default/minio"; exit 1; fi (code=exited, status=0/SUCCESS)
Main PID: 9085 (code=exited, status=1/FAILURE)
Dec 23 17:11:56 iZbp1icuzly3aac0dmjz9aZ systemd[1]: minio.service: Main process exited, code=exited, status=1/FAILURE
Dec 23 17:11:56 iZbp1icuzly3aac0dmjz9aZ systemd[1]: minio.service: Failed with result 'exit-code'.
Dec 23 17:11:56 iZbp1icuzly3aac0dmjz9aZ systemd[1]: minio.service: Service hold-off time over, scheduling restart.
Dec 23 17:11:56 iZbp1icuzly3aac0dmjz9aZ systemd[1]: minio.service: Scheduled restart job, restart counter is at 5.
Dec 23 17:11:56 iZbp1icuzly3aac0dmjz9aZ systemd[1]: Stopped MinIO.
Dec 23 17:11:56 iZbp1icuzly3aac0dmjz9aZ systemd[1]: minio.service: Start request repeated too quickly.
Dec 23 17:11:56 iZbp1icuzly3aac0dmjz9aZ systemd[1]: minio.service: Failed with result 'exit-code'.
Dec 23 17:11:56 iZbp1icuzly3aac0dmjz9aZ systemd[1]: Failed to start MinIO.
It looks like the reason is the Variable MINIO_VOLUMES not set in /etc/default/minio.
However, I double check the file from /etc/default/minio
MINIO_ACCESS_KEY="minioadmin"
MINIO_VOLUMES="/usr/local/share/minio/"
MINIO_OPTS="-C /etc/minio --address localhost:9001"
MINIO_SECRET_KEY="minioadmin"
I have set the value MINIO_VOLUMES.
I tried to start manually with minio server --address :9001 /usr/local/share/minio/, it works.
now I don't know what goes wrong with starting the minio server by using the systemctl start minio
I'd recommend sticking to the official documentation wherever possible. It's intended for distributed deployments but the only real change is that your MINIO_VOLUMES will be for a single node/drive.
I would recommend trying a combination of things here:
Review minio.service and ensure the user/group exists
Review file path permissions on the MINIO_VOLUMES value
Now for the why:
My guess without seeing further logs (journalctl -u minio would have been helpful here) is that this is a combination of two things:
the minio.service user/group doesn't have rwx permissions on the /usr/local/share/minio path,
you are missing an environment variable we recently introduced to prevent users from pointing at their root drive (this was intended as a safety measure, but somewhat complicates these kinds of smaller setups).
Take a look at these lines in the minio.service file - I'm assuming that is what you are using based on the instructions in the DO guide.
If you ls -al /usr/local/share/minio I would venture it has ROOT permissions for user and group and limited write access if any.
Hope this helps - for further troubleshooting having at least 10-20 lines from journalctl is invaluable, as it would show the actual error and not just the final quit message.
I am trying to run a discord bot in a node application in a free Compute Engine instance. I am struggling to make a script that actually starts the node app.
I created this script and added it as startup-script metadata from file:
cd code/movo-tron-2000 && npm start &
I checked that the script runs with sudo google_metadata_script_runner --script-type startup --debug, but when I restart the instance, the app doesn't start. Running sudo journalctl -u google-startup-scripts.service prints the following logs:
Apr 20 12:19:08 bot-vm systemd[1]: Starting Google Compute Engine Startup Scripts...
Apr 20 12:19:09 bot-vm startup-script[691]: INFO Starting startup scripts.
Apr 20 12:19:09 bot-vm startup-script[691]: INFO Found startup-script in metadata.
Apr 20 12:19:09 bot-vm startup-script[691]: INFO startup-script: /startup-od52epug/tmpjy_z4vue: line 1: cd: code/mo
Apr 20 12:19:09 bot-vm startup-script[691]: INFO startup-script: Return code 0.
Apr 20 12:19:09 bot-vm startup-script[691]: INFO Finished running startup scripts.
Apr 20 12:19:09 bot-vm systemd[1]: Started Google Compute Engine Startup Scripts.
I see that the script gets executed, but also gets terminated. The app listened for requests, so it shouldn't get terminated in order to run. I assume that the startup script gets run on the same thread as the google compute engine startup script so it gets terminated in order to continue the vm boot. What should I change in my startup script in order to start my app properly and not have it terminated by the instance?
Edit: I set up the following systemd service and script at their corresponding locations
Service:
[Unit]
Description=Start bot
[Service]
ExecStart=/home/me_adi_hf/code/movo-tron-2000/start.sh
[Install]
WantedBy=default.target
Script:
#!/bin/sh
date > /root/bot_report.txt
du -sh /home/ >> /root/bot_report.txt
But when running sudo systemd start bot.service and then checking it's status with sudo systemd status bot.service am getting this output, indicating Exec format error:
bot-start.service - Start bot
Loaded: loaded (/etc/systemd/system/bot-start.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Tue 2020-04-21 09:43:01 UTC; 9s ago
Process: 19303 ExecStart=/home/me_adi_hf/code/movo-tron-2000/start.sh (code=exited, status=203/EXEC)
Main PID: 19303 (code=exited, status=203/EXEC)
Apr 21 09:43:01 bot-vm systemd[1]: Started Start bot.
Apr 21 09:43:01 bot-vm systemd[19303]: bot-start.service: Failed at step EXEC spawning /home/me_adi_hf/code/movo-tron-2000/start.sh: Exec format error
Apr 21 09:43:01 bot-vm systemd[1]: bot-start.service: Main process exited, code=exited, status=203/EXEC
Apr 21 09:43:01 bot-vm systemd[1]: bot-start.service: Unit entered failed state.
Apr 21 09:43:01 bot-vm systemd[1]: bot-start.service: Failed with result 'exit-code'.
I am not sure what causes the error, since the service file syntax looks correct
I have installed Dante Proxy server by using following methods from the website. But the Server doesn't start and shows the following error. I have tried the steps from other websites also. I searched StackOverflow and saw the same issue in one question. but it has been solved yet. Anyone can solve it or suggest me any other alternative for SOCKS5 proxy server
Job for danted.service failed because the control process exited with error code. See "systemctl status danted.service" and "journalctl -xe" for details.
Error shown in systemctl status danted.service & journalctl -xe
steven#steven-VirtualBox:~$ systemctl status danted.service
● danted.service - LSB: SOCKS (v4 and v5) proxy daemon (danted)
Loaded: loaded (/etc/init.d/danted; bad; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2019-03-10 18:12:42 IST; 2min 59s ago
Docs: man:systemd-sysv-generator(8)
Process: 3400 ExecStart=/etc/init.d/danted start (code=exited, status=1/FAILURE)
Mar 10 18:12:41 steven-VirtualBox systemd[1]: Starting LSB: SOCKS (v4 and v5) proxy daemon (danted)...
Mar 10 18:12:42 steven-VirtualBox danted[3405]: error: /etc/danted.conf: problem on line 11 near token "eth0": could not resolve hostname "eth0
Mar 10 18:12:42 steven-VirtualBox systemd[1]: danted.service: Control process exited, code=exited status=1
Mar 10 18:12:42 steven-VirtualBox danted[3400]: Starting Dante SOCKS daemon:
Mar 10 18:12:42 steven-VirtualBox systemd[1]: Failed to start LSB: SOCKS (v4 and v5) proxy daemon (danted).
Mar 10 18:12:42 steven-VirtualBox systemd[1]: danted.service: Unit entered failed state.
Mar 10 18:12:42 steven-VirtualBox systemd[1]: danted.service: Failed with result 'exit-code'.
steven#steven-VirtualBox:~$ journalctl -xe
-- The result is failed.
Mar 10 18:11:40 steven-VirtualBox systemd[1]: danted.service: Unit entered failed state.
Mar 10 18:11:40 steven-VirtualBox systemd[1]: danted.service: Failed with result 'exit-code'.
Mar 10 18:12:40 steven-VirtualBox sudo[3397]: steven : TTY=pts/18 ; PWD=/home/steven ; USER=root ; COMMAND=/bin/systemctl restart danted
Mar 10 18:12:41 steven-VirtualBox sudo[3397]: pam_unix(sudo:session): session opened for user root by (uid=0)
Mar 10 18:12:41 steven-VirtualBox systemd[1]: Stopped LSB: SOCKS (v4 and v5) proxy daemon (danted).
-- Subject: Unit danted.service has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit danted.service has finished shutting down.
Mar 10 18:12:41 steven-VirtualBox systemd[1]: Starting LSB: SOCKS (v4 and v5) proxy daemon (danted)...
-- Subject: Unit danted.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit danted.service has begun starting up.
Mar 10 18:12:42 steven-VirtualBox danted[3405]: error: /etc/danted.conf: problem on line 11 near token "eth0": could not resolve hostname "eth0
Mar 10 18:12:42 steven-VirtualBox danted[3405]: alert: mother[1/1]: shutting down
Mar 10 18:12:42 steven-VirtualBox systemd[1]: danted.service: Control process exited, code=exited status=1
Mar 10 18:12:42 steven-VirtualBox danted[3400]: Starting Dante SOCKS daemon:
Mar 10 18:12:42 steven-VirtualBox sudo[3397]: pam_unix(sudo:session): session closed for user root
Mar 10 18:12:42 steven-VirtualBox systemd[1]: Failed to start LSB: SOCKS (v4 and v5) proxy daemon (danted).
-- Subject: Unit danted.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit danted.service has failed.
--
-- The result is failed.
Mar 10 18:12:42 steven-VirtualBox systemd[1]: danted.service: Unit entered failed state.
Mar 10 18:12:42 steven-VirtualBox systemd[1]: danted.service: Failed with result 'exit-code'.
Mar 10 18:12:50 steven-VirtualBox sudo[3407]: steven : TTY=pts/18 ; PWD=/home/steven ; USER=root ; COMMAND=/bin/systemctl status danted
Mar 10 18:12:50 steven-VirtualBox sudo[3407]: pam_unix(sudo:session): session opened for user root by (uid=0)
Mar 10 18:14:38 steven-VirtualBox sudo[3407]: pam_unix(sudo:session): session closed for user root
I had the same issue and came across your question. I fixed it by adding a systemd dependency of network-online.target to the danted.service, based on reading this https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
Here's how:
sudo systemctl edit danted.service
add this:
[Unit]
After=network-online.target
Wants=network-online.target
save & exit, run this for good measure
sudo systemctl daemon-reload
sudo systemctl enable danted.service
This line is the telltale:
Mar 10 18:12:42 steven-VirtualBox danted[3405]: error: /etc/danted.conf: problem on line 11 near token "eth0": could not resolve hostname "eth0
It looks like there is no interface called eth0.
I had the same issue, found out what the actual interface is called using ifconfig and swapped out eth0 for that.
Find the interface of your device from Terminal with netstat -rn and look at the Iface column. Install netstat with sudo apt install net-tools if you don't have it. Change the settings of external: eth0 to external: xxxx where of course xxxx being your Iface value, in the file /etc/danted.conf.
If you're just starting out and there's not yet saved rules in danted.conf you can simply delete the file with sudo rm /etc/danted.conf and then create a new with sudo nano /etc/danted.conf. If using firewall it is mandatory that you open the port 1080 with sudo ufw allow 1080. In the new empty file danted.conf, paste in
logoutput: syslog
user.privileged: root
user.unprivileged: nobody
# The listening network interface or address.
internal: 0.0.0.0 port=1080
# The proxying network interface or address.
external: xxxx #Replace xxxx with the device's Iface
# socks-rules determine what is proxied through the external interface.
socksmethod: username
# client-rules determine who can connect to the internal interface.
clientmethod: none
client pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
}
socks pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
}
Save the file and run
sudo systemctl restart danted.service
sudo systemctl status danted.service
I have written a golang RestAPI based on labstack/echo and vuejs and have a working version compiled and everything runs nicely when I start it. So far so good.
However when trying to integrate it with systemd to start the process at boot I am stuck. I have a service file.
[Unit]
Description=Server Software Manager
After=network.target
[Service]
Type=simple
ExecStart=/var/gameserver/steam/sman
KillMode=process
User=steam
Group=steam
Restart=on-failure
SuccessExitStatus=2
[Install]
WantedBy=multi-user.target
Alias=sman.service
But everytime I want to start the service I get the following error.
Feb 25 14:17:49 <SERVERNAME> systemd[1]: Stopped Server Software Manager.
Feb 25 14:17:49 <SERVERNAME> systemd[1]: Started Server Software Manager.
Feb 25 14:17:49 <SERVERNAME> systemd[1]: sman.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Feb 25 14:17:49 <SERVERNAME> systemd[1]: sman.service: Unit entered failed state.
Feb 25 14:17:49 <SERVERNAME> systemd[1]: sman.service: Failed with result 'exit-code'.
Feb 25 14:17:50 <SERVERNAME> systemd[1]: sman.service: Service hold-off time over, scheduling restart.
Feb 25 14:17:50 <SERVERNAME> systemd[1]: Stopped Server Software Manager.
Feb 25 14:17:50 <SERVERNAME> systemd[1]: sman.service: Start request repeated too quickly.
Feb 25 14:17:50 <SERVERNAME> systemd[1]: Failed to start Server Software Manager.
Feb 25 14:19:59 <SERVERNAME> systemd[1]: Started Server Software Manager.
According to google that error is when the Service exits with error code but when I run the Service manually as the steam user it does not do that.
My assumption is that something is wrong with that unit file but I don't know what. And Systemd-analyze has also not complained.
I am completely lost and thankful for any leads you might have help debug this.
The output of jounarlctl -xfe -u sman:
Feb 26 14:18:23 <SERVERNAME> systemd[1]: Started Server Software Manager.
-- Subject: Unit sman.service has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit sman.service has finished starting up.
--
-- The start-up result is done.
Notes:
OS: Ubuntu 16.04 LTS
I finally managed to find out what was wrong. Systemd needs all Env Variables explicitly mentioned. However it looks like I had loads of troubles reloading systemd services. This is what i've ended up doing. the service needs to be stoped, the .service file moved to a location systemd does not read, after that reload systemd with systemctl daemon-reload and wait until systemctl status $SERVICE claims there is no such service. (Systemd might still reread the cache if status claims anything else) After that add the .service file again to the appropriate location and voila it finaly worked.
In Raspbian Stretch Lite I created the following systemd service:
[Unit]
Description=Autostart
After=multi-user.target
[Service]
Type=forking
ExecStart=/home/pi/autostart.sh
User=pi
Group=pi
[Install]
WantedBy=multi-user.target
Here the content of autostart.sh:
#!/bin/sh -ex
export TERM=linux
clear
mkdir -p /home/pi/logs
/home/pi/bin/./TestApp&
The script is actually executed (I added a debug echo to a file) but the application is not launched. It's a Qt5 console application, not a GUI one.
Trying to manually launch the script (i.e. ./autostart.sh) works as expected.
Instead, manually start the service leads to this output:
$ sudo systemctl start autostart.service
$ systemctl status autostart.service
● autostart.service - Autostart
Loaded: loaded (/lib/systemd/system/autostart.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2017-09-28 19:56:33 CEST; 9s ago
Process: 1351 ExecStart=/home/pi/autostart.sh (code=exited, status=0/SUCCESS)
Main PID: 1354 (code=exited, status=127)
Sep 28 19:56:33 localhost systemd[1]: Starting Autostart...
Sep 28 19:56:33 localhost autostart.sh[1351]: + export TERM=linux
Sep 28 19:56:33 localhost autostart.sh[1351]: + clear
Sep 28 19:56:33 localhost autostart.sh[1351]: [34B blob data]
Sep 28 19:56:33 localhost systemd[1]: Started Autostart.
Sep 28 19:56:33 localhost systemd[1]: autostart.service: Main process exited, code=exited, status=127/n/a
Sep 28 19:56:33 localhost systemd[1]: autostart.service: Unit entered failed state.
Sep 28 19:56:33 localhost systemd[1]: autostart.service: Failed with result 'exit-code'.
It's ok the mkdir command is not executed (the directory is already there), but I don't understand why application is not executed.
What could I do to get more information about what's happening?
First, running in the background is not the same as forking.
You can get rid of your autostart script and make a simpler systemd config file.
remove Type=forking. The default is Type=simple, which will handle running your app in the background for you.
Set Environment="TERM=linux" directly in the system configuration.
You can have multiple ExecStart= lines. Add a first one that is ExecStart=-/bin/mkdir -p /home/pi/logs, the extra "dash" there will allow the command to 'succeed' even if the directory has already been made.
Finally, run your app with ExecStart=/home/pi/bin/TestApp
Related man pages are man systemd.service, man systemd.exec, or look up any directive with man systemd.directives.