Wyłączanie sie servera vps

Rozumiem, że chodzi ci o wyłączający się przykładowo serwer gry, a nie serwer VPS. Serwer VPS to jakby cały system operacyjny.

Najprawdopodobniej uruchamiasz go bezpośrednio w konsoli. Jeśli chcesz, aby działał on po jej zamknięciu, musisz użyć aplikacji typu screen lub tmux. Jej działanie oraz sposób użycia jest opisany w tych poradnikach:

https://lvlup.rok.ovh/t/podstawy-aplikacji-screen/306?u=timo https://lvlup.rok.ovh/t/tmux-alternatywa-dla-aplikacji-screen/14246?u=timo

Ja osobiście używam tmux i go polecam. Według mnie wygodniejszy.

Lecz ja używam screen do odpalenia serwera i on i tak się wyłącza wiec nie wiem o co chodzi.

W jaki sposób wyłączasz terminal? Wychodzisz najpierw ze screena przez ctrl+a i ctrl+d?

Nie, zamykam po prostu

Co pojawia się w logach serwera, gdy jest zamykany? Spróbuj też zamykać terminal odłączając się najpierw od sesji screena, tak jak napisałem.

o takie cos sie pokazuje Może to wina screena wysle zdjecie z nim

Próbowałem nie działa

I jaką dokładnie komendą uruchamiasz ten skrypt?

bash start.sh

W takim razie nie odpalasz serwera w screenie, tylko zwyczajnie w terminalu. Owszem uruchamiasz skrypt, ale przestaje on działać gdy rozłączysz sesję.

Zmień komendę na: screen -dmS serwer bash start.sh Wtedy będzie on chodził w tle, a żeby zobaczyć konsolę użyj: screen -r serwer

Albo prościej dodać w pliku bash screen -dmS serwer i wtedy mamy ładną komendę ./start.sh do odpalenia :harold:

Dziękuje jesteś wielki

Tym razem jak zamknę konsole to serwer działa ale po jakimś czasie sam się zamyka wiec nadal pomocy potrzebuje.

Powodów może być kilka, w tym najbardziej prozaiczny to "zeżarcie" przez Javę RAMu do tego stopnia że kernel ubija serwer gier.

Musiałbyś zerknąć albo do dziennika (komenda journalctl, przy czym trochę powinieneś orientować się czego szukasz) albo obserwować zasoby przez htop albo nawet zerknąć do panelu tam gdzie masz VPS i są jakieś statystyki czy czasem RAM nie osiągnął "sufitu".

Z ramem jest wszystko okej wiec nie wiem o co chodzi.

Przy włączaniu procesu serwera w jednej linii, w następujący sposób: screen -dmS serwer bash start.sh włączany jest proces screena i proces javy, jednak, gdy screena włączysz w ten sposób: screen -dmS serwer, a potem już w tym screenie włączysz skrypt to najpierw uruchamiany jest dodatkowy proces powłoki systemowej, co przekłada się na użycie więcej zasobów serwera (dodatkowa powłoka). Żeby to zwizualizować, moim procesem jest "sleep 600"

screen -dmS serwer [komenda]

screen -dmS serwer, potem sleep 600

Nie jest to jakieś wysoce istotne, jeżeli uruchamiamy jeden serwer, jednak w wypadku większej liczby screenów warto mieć to na uwadze, bo na każdym takim procesie można zaoszczędzić trochę ramu (w zależności od tego, jak działa child-proces).

No dokładnie, najlepiej to w ogóle odpalać serwer Minecraft jako PID 1, bo wiadomo, że inaczej się ram marnuje jak jakiekolwiek zbędne child procesy są. 🥳

# bash -> sleep
~$ sudo pmap 14404 | grep total
 total             8840K
# sleep
~$ sudo pmap 14400 | grep total
 total             8708K

Wspaniała oszczędność 132 KB. 😎

Nieznajomy11:

Wspaniała oszczędność 132 KB.

Zachęcam do przeczytania mojego wpisu raz jeszcze:

Axerr:

Nie jest to jakieś wysoce istotne, jeżeli uruchamiamy jeden serwer, jednak w wypadku większej liczby screenów warto mieć to na uwadze, bo na każdym takim procesie można zaoszczędzić trochę ramu (w zależności od tego, jak działa child-proces).

Axerr:

Zachęcam do przeczytania mojego wpisu raz jeszcze:

Do której części się odnosisz? Niezależnie — wypadałoby przedstawić faktyczne dane, a nie swoją opinię. Ile to jest "trochę ramu"? 1MB? 5MB?

Na każdym takim bashu można zaoszczędzić 7.3 MB RAMu. Powtórzę się, że nie ma to zastosowania przy jednym serwerze, jednak jeżeli ktoś chciałby uruchomić przykładowo 100 screenów (wiele aplikacji róznego typu, czemu by nie?) to można zaoszczędzić niecały gigabajt pamięci RAM. @Nieznajomy11 Twoje wyśmiewcze uwagi typu "wspaniała oszczędność' są tutaj zbędne. W swoim poście wspomniałem o warunkach, w których to ma faktycznie sens.

Axerr:

Na każdym takim bashu można zaoszczędzić 7.3 MB RAMu.

Czy oby na pewno nie przedstawiłeś samodzielnie pracującego procesu bash zamiast różnicy między dwoma sposobami uruchamiania aplikacji poprzez screen? To bardzo ważna różnica.

Wymagana jest tutaj wiedza odnośnie działania subshelli — podczas tworzenia takiego rodzaju procesu jest wykorzystywana metoda fork. Dzięki temu większość pamięci jest współdzielona, tylko niewielka ilość to będzie faktyczne dodatkowe zużycie — może się okazać, że nawet praktycznie zerowe.

Zachęcam do samodzielnego przeprowadzenia eksperymentu i odpalenia dużej ilości subshelli, po czym zweryfikowania używając pmap najwyższego procesu z odpalonym pojedynczym bashem a np. 1000:

Wyniki mogą wydawać się nieprawidłowe, ale to po prostu tak działa zarządzanie pamięcią child procesów na linuksie. Więcej wytłumaczenia jest też na dole podlinkowanej strony man.

Ten temat został automatycznie zamknięty 32 dni po ostatnim wpisie. Tworzenie nowych odpowiedzi nie jest już możliwe.