Ik zou er soms toch gewoon een schop in kunnen geven, in de mannen van Dreamhost.
19 januari 01u08: gemeld dat mijn site plat ligt
My site at blog.zog.org is down with a bad_httpd_conf error.
I did some DNS changes recently, could that be the reason?
19 januari 02u47: gevraagd, om zeker te zijn, naar het correcte IP-adres
Just to confirm this: the correct IP for blog.zog.org that I need to refer to via an A record is 64.111.114.126, right?
Niets gehoord, dagen aan een stuk. Ondertussen de site verhuisd naar Typepad, en bedacht dat ze daarmee misschien niet meer zouden weten wat er aan de hand was bij Dreamhost (niet dat dat eigenlijk een probleem zou moeten geven, maar goed, een mens doet om goed te doen).
21 januari, 03u44: alles nog eens verduidelijkt
In case you’re looking at my previous support requests (#1216412, #1216373) and wondering what they are about: I temporarily changed blog.zog.org’s DNS information to point it, via a CNAME, to a TypePad weblog.
I’d like to move it back to my wordpress weblog at Dreamhost (A record to Dreamhost), but I’m not ready to do that unless I know I’m not going to have any downtime… so:
(1) could you please tell me the correct IP address I have to point the A record to? Is it 64.111.114.126?
(2) can you guarantee me that once I do effectuate the DNS change, I’ll not be greeted with a bad_httpd_conf error?
Bijna drie dagen geen antwoord, en dan dit:
Hello,
On Thu, 19 Jan 2006, you wrote:
> My site at blog.zog.org is down with a bad_httpd_conf error.
> I did some DNS changes recently, could that be the reason?Yes, when our systems are catching up with configurations, this error is shown. It is temporary.
Thanks!
Terri
Aaaargh!!! Alledrie mijn support requests als “opgelost” geklasseerd, en daarmee ben ik dus geen stap verder! Fuck!
Daarnet nog eens geprobeerd om de A record aan te passen naar het IP-nummer dat Dreamhost me zegt dat het zou moeten zijn, maar neen dus: weer zo’n bad_httpd_conf. En nu hebben ze het excuus niet dat mijn configuratie nog moet aan “catching up” doen, want ze staat bij Dreamhost al meer dan vijf dagen onveranderd.
Dus nog maar eens een support request ingediend, en nog maar eens voorlopig alles via CNAME terug naar TypePad gestuurd.
Fuckers.
Reacties
4 reacties op “Ah fer fuck’s sake”
Juk, alweder sysadmins die er zich snel vanaf maken in de hoop dat “de gebruiker er toch niets van kent”.
Geloof me, geen uniek geval… Zelf ook al last mee gehad bij een vlaams bedrijf, zelfs geen kleintje, ’t begint met een C enzo. Vreselijk irritant.
Geen zin te investeren in een eigen dedicated server? Zelf al vaker aan gedacht, heb een goed aanbod, maar studentenfinanciën en aankoop van een 1U server gaan niet echt samen 😀
(Om geen of andere reden kan ik geen commentaar geven op “Gedomme”, het vervolg van deze saga, dus probeer ik hier even opnieuw.)
Met
lsofkunt ge kijken naar (onder andere) de bestanden die processen open hebben staan. Daar ziet ge dan hopelijk ook de PHP-scripts in kwestie in.lsof -p 27296bijvoorbeeld.Hm.
lsofgeeft allerlei te verwachten files in gebruik uit/usr/lib/blabla, en helemaal odneraan iets alsphp.cgi 5869 mvuijlst 0r FIFO 0,5 659531019 pipe
php.cgi 5869 mvuijlst 1w FIFO 0,5 659531020 pipe
php.cgi 5869 mvuijlst 2w REG 0,30 8990 828834 /home/…/http.1372493/error.log (10.3.38.176:/vol/boot/…)
php.cgi 5869 mvuijlst 3u sock 0,0 659531027 can’t identify protocol
php.cgi 5869 mvuijlst 4u REG 3,3 0 562216 /usr/local/tmp/ZCUDKmtDpB (deleted)
php.cgi 5869 mvuijlst 5w FIFO 0,5 658156098 pipe
Chinees voor mij. Ik heb ze bij Dreamhost om uitleg gevraagd. 🙂
Niets abnormaal. Die pipes zijn ofwel mysql sockets, of de pipes naar u http proces (ge-emuleerde stdin, stdout,… voor CGI)
error.log spreekt voor zich, en blijkt een NFS mount te zijn
Can’t identify protocol is natuurlijk een beetje raar
Die file in /usr/local/tmp kan een session file zijn, zou je de content moeten zien. Aangezien ie deleted is gok ik op session informatie oid.
Mocht ik van u zijn: strace op hangende processen.