Script starten bij opstart, zonder user login CentOS 7

[NiRo]

Hallo iedereen

Ik heb thuis een servertje staan (op CentOS). Nu wou ik hierop een scriptje laten draaien als de server opstart. Zelfs als niemand inlogt. Ik heb hier de eerste 2 oplossingen geprobeerd maar deze werken allebei niet. Heeft iemand nog een alternatief?

Alvast bedankt!

[MAX3400]

Lijkt me sterk dat een oplossing van Stackoverflow met 94 votes niet werkt.

Oftewel: wat werkt er niet, welke errors kan je terugvinden in je logging, met welke user/permissies denk je het te hebben geimplementeerd, welke attributes heeft het script (mag het wel worden uitgevoerd)?

[ Voor 13% gewijzigd door MAX3400 op 08-08-2017 10:56 ]

[NiRo]

Ja vond ik ook al raar maar het staat in askubuntu.com dus het is voor Ubuntu geschreven. Qua logs, heb ik niet echt een idee waar ik die terugvind. Ik heb alles met root uitgevoerd. Misschien handig om te weten: ik kon geen upstart job aanmaken omdat de map /etc/init niet bestaat in CentOS. Ook het commando van alternatief 3: update-rc.d herkende hij niet bij mij...

[MAX3400]

NiRo schreef op dinsdag 8 augustus 2017 @ 11:00:
ik kon geen upstart job aanmaken omdat de map /etc/init niet bestaat in CentOS. Ook het commando van alternatief 3: update-rc.d herkende hij niet bij mij...

Maaruh, moet je dan niet even een handleiding CentOS erbij zoeken?

Volgens mij staat e.e.a. in /etc/init.d en zal je verder met rc.local en mogelijk chkconfig aan de gang moeten voor een aantal zaken.

Ubuntu en CentOS zijn in de basis hele andere kernels; of je moet het luchtiger zien, commando's uit Windows '95 zijn/lijken ook niet allemaal meer in Windows 10 aanwezig. Namen zijn veranderd / vervangen, nieuwe/andere directories aangemaakt etc.

[Ofniet]

Ik zet mijn opstart scripts altijd in /etc/rc.d/rc.local.
Deze wordt standaard uitgevoerd tijdens het opstarten van CentOs

[CyBeR]

Maak een systemd unit file, zet in /etc/systemd/system en enable die.

[ Voor 1% gewijzigd door CyBeR op 08-08-2017 11:26 . Reden: Andersom. ]

[NiRo]

@MAX3400 Ja, ik weet het... Ik ga eens proberen met rc.local.

@Ofniet En die scripts worden ook uitgevoerd als er niemand inlogt?

@CyBeR Is dat met andere woorden een service? Want daar heb ik nog geen ervaring mee...

[CyBeR]

NiRo schreef op dinsdag 8 augustus 2017 @ 11:17:
@CyBeR Is dat met andere woorden een service? Want daar heb ik nog geen ervaring mee...

Tijd om ervaring te krijgen. Het is vrij simpel.

[MAX3400]

NiRo schreef op dinsdag 8 augustus 2017 @ 11:17:
@CyBeR Is dat met andere woorden een service? Want daar heb ik nog geen ervaring mee...

bootstrap & system process manager

Kan dus heeeel veeeeel (kapot) maken als je er (niet) goed mee om gaat.

Zoals @CyBeR aangeeft; het is simpel om te leren maar ervaring zal je toch echt zelf moeten op doen. Allicht kan je eerst een proberen om een boot-scriptje te maken die een nieuw bestandje in je home-dir schrijft. En daarna een scriptje om bij opstarten een oude log-file (zoals whatever.log.4) weggooit etc.

[Hero of Time]

MAX3400 schreef op dinsdag 8 augustus 2017 @ 10:55:
Lijkt me sterk dat een oplossing van Stackoverflow met 94 votes niet werkt.

Oftewel: wat werkt er niet, welke errors kan je terugvinden in je logging, met welke user/permissies denk je het te hebben geimplementeerd, welke attributes heeft het script (mag het wel worden uitgevoerd)?

Het is logisch dat het niet werkt. Het antwoord is 4 jaar geleden gesteld. Toen was systemd nog helemaal niet in gebruik. CentOS 7 gebruikt systemd, waardoor het antwoord dat daar gegeven wordt niet werkt. Geen van de genoemde zaken wordt aangeroepen namelijk.

NiRo schreef op dinsdag 8 augustus 2017 @ 11:17:
@MAX3400 Ja, ik weet het... Ik ga eens proberen met rc.local.

Let even op dat standaard rc.local niet uitgevoerd wordt met een systemd omgeving. Je moet die apart inschakelen.

@Ofniet En die scripts worden ook uitgevoerd als er niemand inlogt?

Dat is wel het idee.

@CyBeR Is dat met andere woorden een service? Want daar heb ik nog geen ervaring mee...

Ja, het is net als een service. Het is de netste oplossing op dit moment. Ik zie graag je oplossing tegemoet, want ik moet hetzelfde regelen namelijk voor een systeem dat ik voor vrienden beheer.

[Bigs]

systemd maakt dit inderdaad kinderlijk eenvoudig en veel beheersbaarder dan rc.local. Er zijn online genoeg voorbeelden te vinden van systemd unit files en de volledige handleiding vind je hier: https://access.redhat.com...h_systemd-Unit_Files.html

[CyBeR]

Bigs schreef op dinsdag 8 augustus 2017 @ 11:26:
systemd maakt dit inderdaad kinderlijk eenvoudig en veel beheersbaarder dan rc.local. Er zijn online genoeg voorbeelden te vinden van systemd unit files en de volledige handleiding vind je hier: https://access.redhat.com...h_systemd-Unit_Files.html

Juist. En de grap is dat systemd niet distributiespecifiek is, dus advies van Red Hat gaat werken op Ubuntu en vice versa.

Het enige wat je moet doen is een Service unit file maken (dat kan heel simpel, paar regels tekst), die op de goede plek zetten, systemd vertellen dat 't ding bestaat (systemctl daemon-reload) en dat vervolgens enablen (systemctl enable foo.service) en, als je dat wilt wat ik aanneem, starten (systemctl start foo.service).

Systemd zorgt er vervolgens voor dat 't ding gestart wordt bij het booten en dat de output ergens in een log terecht komt (te zien met journalctl -u foo.service).

Als je wilt dat 't script blijft draaien zelfs als 't er mee stopt, zet je 'Restart=always' in je unit file, als 't dan crasht dan zorgt systemd er voor dat 'ie weer opgestart wordt.

't is iets meer moeite dan een regel in rc.local pasten maar je krijgt er dan ook wel wat voor terug.

[ Voor 3% gewijzigd door CyBeR op 08-08-2017 11:55 ]

[vanaalten]

Hero of Time schreef op dinsdag 8 augustus 2017 @ 11:24:
[...]

Het is logisch dat het niet werkt. Het antwoord is 4 jaar geleden gesteld. Toen was systemd nog helemaal niet in gebruik. CentOS 7 gebruikt systemd, waardoor het antwoord dat daar gegeven wordt niet werkt. Geen van de genoemde zaken wordt aangeroepen namelijk.

Ergens verderop werd crontab nog als oplossing genoemd. Als je inderdaad cron geinstalleerd hebt, zou een "@reboot" regel in /etc/crontab dan kunnen werken?

[SadisticPanda]

Kan ook makkelijk op redelijk universele manier.

Crontab openen:

@reboot /path/naar/scriptfile

Ez pz


Edit: verdorie sniped door @vanaalten

[ Voor 18% gewijzigd door SadisticPanda op 08-08-2017 12:42 ]

[NiRo]

Okee, dus ik heb een systemd unit file gemaakt:

code: minecraft.service

[Unit]
Description=Minecraft Server starter
After=network.target

[Service]
ExecStart=/home/minecraft/Server/run.sh
Type=oneshot

[Install]
WantedBy=default.target

En het script run.sh ziet er zo uit:

code: run.sh

#! /bin/bash

# opent server
cd /home/minecraft/Server/INFINITYNATIONS/BungeeCord
screen -d -m -S bungeecord ./start.sh
cd /home/minecraft/Server/INFINITYNATIONS/SpawnLobby
screen -d -m -S lobby ./start.sh
cd /home/minecraft/Server/INFINITYNATIONS/GodArnoRo
screen -d -m -S godarnoro ./start.sh

Dus wat er gebeurt: de scripts voor de minecraft server te starten moeten in een screen sessie gestart worden. Ik heb run.sh al in Startup applications gezet maar dat werkt dus alleen als je inlogt. Nu, wat is er mis met de unit file? Als ik sysconfig status minecraft.service doe, krijg ik als output dat het inactief(dead) is en dat het script gestart is. Als ik echter screen -ls doe, zijn er geen sockets actief. Wat doe ik fout aan die unit file? Alvast bedankt!

[CyBeR]

Om te beginnen, is er een reden dat je die drie processen in een screen wilt hebben? Dit klinkt alsof je gewoon drie unit files voor die drie services moet maken.

[Hero of Time]

Systemd moet het proces kunnen monitoren. Dat kan het met dit niet, dus ziet het als 'inactive'. Maar wil je MC echt als root draaien? Lijkt mij niet. Je kan dan beter @reboot in de cron van de gebruiker zetten met het volledige pad naar het start.sh script.

[CyBeR]

Hero of Time schreef op dinsdag 8 augustus 2017 @ 19:37:
Systemd moet het proces kunnen monitoren. Dat kan het met dit niet, dus ziet het als 'inactive'. Maar wil je MC echt als root draaien? Lijkt mij niet. Je kan dan beter @reboot in de cron van de gebruiker zetten met het volledige pad naar het start.sh script.

Systemd units hoeven, uiteraard, niet als root te draaien.

[Hero of Time]

CyBeR schreef op dinsdag 8 augustus 2017 @ 19:37:
[...]

Systemd units hoeven, uiteraard, niet als root te draaien.

Klopt, maar zoals hij het nu heeft doet dat 't wel.

[NiRo]

@CyBeR Ja, namelijk dat ik de console van de server moet kunnen bedienen, dus het wordt een aparte omgeving waar je de server commando's kunt uitvoeren.

@Hero of Time Ja, dat inactieve maakt voor mij niet uit echt uit, zolang het script maar uitgevoerd wordt, ondanks niemand inlogt. MC moet uiteraard niet als root draaien, hoe laat je dan de unit als gewone user draaien? Als dat niet gaat, hoe doe je dat dan met een cronjob?

[CyBeR]

NiRo schreef op dinsdag 8 augustus 2017 @ 19:59:
@CyBeR Ja, namelijk dat ik de console van de server moet kunnen bedienen, dus het wordt een aparte omgeving waar je de server commando's kunt uitvoeren.

Dat is echt een idiote manier van werken dus ik kan me bijna niet voorstellen dat dat niet anders kan…

Iig, iets als een andere user uitvoeren is een kwestie van 'User=bla' toevoegen.

[NiRo]

Kleine update van de unit file (werkt nog steeds niet, wat doe ik fout?)

code: minecraft.service

[Unit]
Description=Minecraft Server starter
After=network.target

[Service]
ExecStart=/home/minecraft/Server/run.sh
User=minecraft

[Install]
WantedBy=graphical.target

Als output van journalctl geeft hij dit:

code:

Starting Minecraft server starter
Started Minecraft server starter

En ja, ik vind het ook omslachtig maar het kan niet anders.

[vanaalten]

NiRo schreef op woensdag 9 augustus 2017 @ 10:48:
Kleine update van de unit file (werkt nog steeds niet, wat doe ik fout?)

code: minecraft.service

[Unit]
Description=Minecraft Server starter
After=network.target

[Service]
ExecStart=/home/minecraft/Server/run.sh
User=minecraft

[Install]
WantedBy=graphical.target

Als output van journalctl geeft hij dit:

code:

Starting Minecraft server starter
Started Minecraft server starter

En ja, ik vind het ook omslachtig maar het kan niet anders.

Ik zou met "ps -fe" of zo eens kijken bij alle lopende processen: is de server actief?

Daarnaast:

NiRo schreef op dinsdag 8 augustus 2017 @ 11:00:
Qua logs, heb ik niet echt een idee waar ik die terugvind.

... denk ik dat dit toch echt een probleem is: in die logs kan je het gros van de oorzaken van fouten vaak terugvinden, dus lijkt mij heel zinnig om je in te leren in waar die dingen staan en wat er in staat.

[NiRo]

In de logs van journalctl vind ik alleen dat hij de service start. Dus de unit file klopt wel, maar de screen sessie wordt niet gestart...

[MAX3400]

NiRo schreef op woensdag 9 augustus 2017 @ 13:04:
In de logs van journalctl vind ik alleen dat hij de service start. Dus de unit file klopt wel, maar de screen sessie wordt niet gestart...

Heb je de screen-sessie al eens gestart op de commandline zelf als de user waarmee je de startup-service wil starten? Grote kans dat je dan namelijk een error krijgt met een bepaalde verwijzing erin waar het fout gaat.

Begin eerst: commando uitvoeren zonder screen
Daarna: commando uitvoeren met screen

[MarkdV]

Ik kan me niet voorstellen dat er nog nooit iemand eerder is geweest die een Minecraft server wil draaien op een systeem welke gebruik maakt van systemd.

Dus na een korte search kwam ik het volgende tegen:
https://github.com/agowa338/MinecraftSystemdUnit/

Daarmee heb je dus 1 service file, die je in jouw geval 3 keer enabled met de verschillende istances en je voor zover ik kan zien afgeschermde Minecraft servers kan starten.

[CyBeR]

Dat is een veel betere manier inderdaad. Ik was net zoiets zelf even aan 't bekijken maar dit is lekker voorgekauwd.

[NiRo]

Mijn unit file ziet er nu zo uit:

code:

[Unit]

Description=Minecraft Server %i



[Service]

WorkingDirectory=/home/minecraft/Server/INFINITYNATIONS/minecraft-%i

User=minecraft



ExecStart=/usr/bin/screen -DmS %i-mc-%i ./start.sh 



ExecStop=/usr/bin/screen -p 0 -S %i-mc-%i -X eval 'stuff "say SERVER SHUTTING DOWN. Saving map..."\\015'

ExecStop=/usr/bin/screen -p 0 -S %i-mc-%i -X eval 'stuff "autosave"\\015'

ExecStop=/usr/bin/screen -p 0 -S %i-mc-%i -X eval 'stuff "stop"\\015'

ExecStop=/bin/sleep 2



[Install]

WantedBy=multi-user.target

De file werkt al als ik het handmatig doe, nu alleen wachten tot morgen, om 8h moet het uitgevoerd worden. Heel erg bedankt voor alle reacties en hulp!!