2015-11-26 9 views
5

पर अनुमति की अनुमति के कारण पोस्टग्रेस सर्वर प्रारंभ करने में असमर्थ, मैंने अपने पोस्टग्रेस सर्वर को पुनरारंभ किया लेकिन अब। मैंने अपनी "pgstartup.log" लॉग फ़ाइल की जांच की। यह कहते हैं:लॉक फ़ाइल

creating system views ... ok 
loading system objects' descriptions ... ok 
creating conversions ... ok 
creating dictionaries ... ok 
setting privileges on built-in objects ... ok 
creating information schema ... ok 
vacuuming database template1 ... ok 
copying template1 to template0 ... ok 
copying template1 to postgres ... ok 

Success. You can now start the database server using: 
/usr/bin/postgres -D /var/lib/pgsql/data 
/usr/bin/pg_ctl -D /var/lib/pgsql/data -l logfile start 

FATAL: could not open lock file "/tmp/.s.PGSQL.5432.lock": Permission denied 
FATAL: could not open lock file "/tmp/.s.PGSQL.5432.lock": Permission denied 

आपको लगता है /tmp/.s.PGSQL.5432.lock को हटाने काम करेगा है?

+0

इसे हटाएं और हमें बताएं ... सही? :) परिभाषा के अनुसार आप/tmp फ़ोल्डर से कुछ भी हटा दें। हालांकि समस्या फिर से हो सकती है, पोस्ट के लिए इस्तेमाल किए गए उपयोगकर्ता को चेक करें/tmp – mikus

उत्तर

2

PostgreSQL सामान्य रूप से लॉक फ़ाइल को सामान्य रूप से समाप्त करते समय हटा देता है।

शायद यह किसी अन्य पोस्टग्रेएसक्यूएल उदाहरण के कारण एक अलग उपयोगकर्ता के साथ चल रहा है जिसे असामान्य रूप से समाप्त किया गया है (पोस्टमास्टर को मार -9)।

तो, यदि आप सुनिश्चित हैं कि कोई पोस्टग्रेस प्रक्रियाएं चल रही हैं, तो आप शायद बिना किसी समस्या के उस फ़ाइल को हटा सकते हैं। यदि कोई स्टाइल साझा मेमोरी सेगमेंट है तो आपको ipcs कमांड के साथ भी जांच करनी चाहिए, और उस स्थिति में इसे ipcrm से हटा दें।

शायद इन सभी चीजों को हल करने का सबसे अच्छा तरीका सर्वर को रिबूट करना है।

पीएस .: कभी kill -9 कोई पोस्टग्रेएसक्यूएल प्रक्रिया नहीं।

+1

से फ़ाइलों को एक्सेस करने और हटाने के लिए सभी विशेषाधिकार हैं ध्यान दें कि यह सॉकेट लॉक है, न कि 'postmaster.pid' –

+0

हां, लेकिन मैं नहीं करता एक मारे गए पोस्टमास्टर के बगल में एक बाँध लॉकफाइल छोड़ने के किसी भी तरीके से जानें। दूसरी संभावना यह है कि लॉकफाइल पुराना नहीं था और पोस्टमास्टर इसे अभी भी पूरी तरह से अलग-अलग 'listen_address' पर चला रहा था (टीसीपी सॉकेट यूनिक्स से पहले खोला गया है) – mnencia

1

ऐसा लगता है कि आपके पास एक अलग उपयोगकर्ता के रूप में एक ही पोर्ट पर एक और पोस्टग्रेएसक्यूएल उदाहरण चल रहा है, या आपने पहले इस पोस्टग्रेएसक्यूएल इंस्टेंस को एक अलग उपयोगकर्ता के रूप में शुरू किया था और फिर इसे अशुद्ध रूप से रोक दिया था।

चेक /tmp/.s.PGSQL.5432.lock के स्वामित्व:

ls -l /tmp/.s.PGSQL.5432.lock 

यह उपयोगकर्ता के रूप में आप PostgreSQL चला रहे हैं मेल खाता है?

/tmp/ में लॉक फ़ाइलों को हटाने के लिए अपेक्षाकृत हानिकारक है। (कभी नहीं, कभीpostmaster.pid लॉक फ़ाइल को हटाएं)। यदि अन्य PostgreSQL इंस्टेंस अभी भी चल रहा है, तो आप इसे यूनिक्स सॉकेट पर कनेक्ट करने की क्षमता खो देंगे, या आपको टीसीपी पर पोर्ट 5432 से जुड़ने में असमर्थ होने में त्रुटि हो सकती है।

मैं @mencia से सहमत हूं कि सर्वर रीबूट सबसे आसान विकल्प है यदि यह आसान और व्यावहारिक है।

+0

हाय सब, सुझावों के लिए धन्यवाद। –

0

सुझावों के लिए धन्यवाद। सबसे पहले मैंने लॉक फ़ाइल की अनुमति बदलने की कोशिश की लेकिन यह काम नहीं किया बाद में मैंने लॉक फ़ाइल को हटा दिया जिसने मेरी समस्या का समाधान किया।

धन्यवाद

संबंधित मुद्दे