Portek

A co to za problem zarejestrować swoją własną licencje NPL? http://npl.teamspeakusa.com/ts3npl.php

Informacji w sieci n/t tego błędu jest w sieci multum. Z autopsji wiem że działa 99.9% z nich, kwestia chęci wyszukania jednego poradnika z pierdyliona innych... http://sleepycode.com/2010/12/convert-ts3-from-sqlite-to-mysql-database/ http://ubuntuforums.org/showthread.php?t=1877721 https://freevps.us/printthread.php?tid=4251 Każde z nich poprawnie wykonane spowoduje odpalenie serwera.

Gdyby nie fakt że mam jeszcze kilkadziesiąt złociszy w portfelu to pewnie bym tak zrobił, jednak od dłuższego czasu - właściwie od początku współpracy do sławnego padu macierzy, wszystko było okej, więc jeszcze ich nie przekreślam :-) Na plus jest support, który w 10min od zgłoszenia "coś" próbował zrobić. No nic Panowie, dziękuję za pomoc i rady. Odzyskałem sporą część danych, z tego co mam odbuduję swoje strony, niestety do tej pory nie dostałem wiadomości z BOK'u co było powodem tego błędu.

Dokładnie, tyle że jak przyjrzeć się pliką to część z nich wyparowała w kosmos. Folder użytkownika X jest, ale użytkownika Y zniknął. Generalnie wygląda to śmiesznie, nie mam ochoty dłużej czekać na support, sam jestem bezradny. Zrobię kopię tego co mi zostało i postawię usługi na nowo.

Partycje mam jedną, montowaną właśnie pod /dev/sdb1. W prawdzie revocery widzi jeszcze sdb2 tyle że to swap, i sda w którym montowany jest obraz systemu recovery. Raczej wątpię że padły im znów dyski czy ram, u mnie to wygląda tak że po naprawieniu via fsck nadal nie działa - mimo że powinno.

Witajcie, pytanie do Was, bardziej doświadczonych użytkowników i administratorów. Mam "drobny" problem z moim VPS'em, wczoraj wieczorem zaliczył defekt, partycja która była mu przydzielona, nagle dziwnym trafem została oznaczona jako "tylko do odczytu", wszystkie usługi zaczęły wariować, w efekcie czego portal i forum padło. W ruch poszło polecenie fsck, partycja została sprawdzona, naprawiona i w celu wprowadzenia zmian miałem wykonać reboot. Tutaj niestety pies pogrzebany, system nie wstaje, nie widzi partycji która nadal gdzieś tam jest, zamiast systemu widzę magiczny komunikat: Target filesystem doesn't have requested /sbin/init. No init found. Try passing init= bootarg. /bin/sh: can't access tty; job control turned off Jako szczęśliwy posiadacz tryby recovery, odpalam go i jeszcze raz, przy pomocy fsck próbuję reanimować partycje, wszystko wygląda okej, po raz kolejny sprawdzona, naprawiona ( /dev/sdb1: clean, 72091/1638400 files, 2458779/6553600 blocks ), reboot i? I nadal ten sam error. Dodam że po zamontowaniu partycji w trybie recovery mam do niej dostęp, pliki więc mogę skopiować, ale nie bardzo uśmiecha mi się ponowna instalacja i konfiguracja tego wszystkiego. Tutaj pojawia się owo wyżej wspomniane pytanie, czy istnieje opcja żeby partycje uratować i obejść się bez reinstalacji systemu? Dane mogę skopiować, tyle że chce rozwikłać zagadkę, dlaczego nagle z dnia na dzień partycja odmówiła posłuszeństwa - na serwerze nie byłem od dość dawna, ze względu prostego - wszystko działało i nie było najmniejszej potrzeby gdziekolwiek grzebać. OS: Debian 6 Firma: Sławny e24cloud Bok stara się pomóc jak może, tyle że obecnie zostałem zwiedziony magicznym "technicy sprawdzają".

https://github.com/Austinb/GameQ - niezależna kontynuacja GameQ

No bo miało być inaczej, a napisałem jeszcze inaczej... fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; na: fastcgi_param SCRIPT_FILENAME /var/www/ghst.pl/web$fastcgi_script_name;

fastcgi_param PATH_INFO $fastcgi_script_name; na: fastcgi_param SCRIPT_FILENAME /var/www/ghst.pl/web$fastcgi_script_name; Bo jak zadziała PHP to zobaczysz magiczne "File no found" Pewny jesteś że FPM pracuje na porcie 9011?

Maszyny maszynami, ale jakość kuleje czasami. Jeszcze z 2mc temu korzystałem z waszych usługi i po problemach z konfiguracją (po waszej stronie, wedle supportu "coś" się przestawiło) musiałem się czym prędzej wynosić. Na krytyczne zgłoszenie dotyczące powtarzającego się błędu, odpowiedź dostałem bagatela po tygodniu czasu! Coś chyba jest jednak nie tak? Nie jestem jedynym klientem, nie mam supportu premium, ale support 24/7/365 to jakiś żart :-)

Każdy jest alfą i omegą, tak ja też... Gdybym cokolwiek znalazł, to pewnie bym nie pisał, ale widzę że niektórych razi to w oczy... Dostęp do serwera mam tylko Ja, nikt czasu nie zmienia, ani nic - bynajmniej logi o tym milczą.

Szukam rozwiązania problemu, a nie połowicznej naprawy.

Zakładając że w ciągu 2h zegar cofa się o 14min, to w 24h będzie to już 168min (ponad 2,5h) więc jest to żadne wyjście. Dlatego też piszę tego posta, postaram się jeszcze raz skontaktować z dostawcą. Zastanawiałem się po prostu czy nie jest to wina gdzieś po stronie wirtualizacji.

Wykonuję aktualizację czasu via ntpdate. Według dostawcy inni klienci takich problemów nie mają.

Witajcie! Mam taki dość denerwujący problem z jednym z VPS-ów (XEN HVM) - w przeciągu nie całych dwóch godzin serwer zaliczył różnicę czasu rzędu 14min. Ciągle nie mogę sobie z tym poradzić, strefa czasowa jest okej, a nadal czas zwyczajnie na świecie kuleje. Nie satysfakcjonuje mnie też za bardzo rozwiązanie z crontabem, raz na godzinę, bo to zwyczajnie bez sensu, a dane są nie spójne. Istnieje jakaś opcja żeby sobie z tym poradzić? System operacyjny Debian 6 (64bit).