Squid shm_open: ਇਜਾਜ਼ਤ ਤੋਂ ਇਨਕਾਰ — ਸਾਂਝੀ ਮੈਮਰੀ ਦੀ ਮਾਲਕੀ ਜਾਂਚੋ

ਇੱਕੋ ਅਸਫਲ Squid ਸ਼ੁਰੂਆਤ ਵੇਲੇ Could not read pid file ਅਤੇ shm_open(...): Permission denied ਦੋਵੇਂ ਦਿਖ ਸਕਦੇ ਹਨ। ਇਹ ਵੱਖਰੇ ਸਰੋਤਾਂ ਦਾ ਨਾਮ ਲੈਂਦੇ ਹਨ। ਕੈਸ਼ ਡਾਇਰੈਕਟਰੀ ਦੀ ਮਾਲਕੀ ਠੀਕ ਕਰਨਾ ਆਪਣੇ ਆਪ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਇੱਕ ਨੂੰ ਵੀ ਠੀਕ ਨਹੀਂ ਕਰਦਾ।

Linux ਉੱਤੇ POSIX ਸਾਂਝੀ ਮੈਮਰੀ ਵਸਤੂ ਆਮ ਤੌਰ 'ਤੇ /dev/shm ਦੇ ਹੇਠ ਦਰਸਾਈ ਜਾਂਦੀ ਹੈ। ਇਸਦਾ ਮਾਲਕ ਅਤੇ ਪਹੁੰਚ ਮੋਡ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਇਸ ਲਈ ਕਿਸੇ ਹੋਰ ਰਨਟਾਈਮ ਪਛਾਣ ਵੱਲੋਂ ਛੱਡੀ ਗਈ ਵਸਤੂ ਬਾਅਦ ਵਾਲੀ ਪਰੋਸੈਸ ਨੂੰ ਅਸਫਲ ਕਰ ਸਕਦੀ ਹੈ, ਭਾਵੇਂ squid.conf ਪੜ੍ਹਨਯੋਗ ਹੋਵੇ ਅਤੇ ਸੁਣਨ ਵਾਲਾ ਪੋਰਟ ਖਾਲੀ ਹੋਵੇ।

ਇਹ ਇੰਸਟੈਂਸ ਕਿਵੇਂ ਸ਼ੁਰੂ ਹੋਇਆ, ਮੁੜ ਬਣਾਓ

ਸੇਵਾ ਦੀ ਆਮ ਸ਼ੁਰੂਆਤ ਦੀ ਤੁਲਨਾ ਸਮੱਸਿਆ ਹੱਲ ਕਰਦੇ ਸਮੇਂ ਵਰਤੀ ਕਿਸੇ ਵੀ ਹੱਥੀ ਸ਼ੁਰੂਆਤ ਨਾਲ ਕਰੋ। ਹੱਥੀਂ ਸ਼ੁਰੂ ਕੀਤੀ ਪਰੋਸੈਸ ਅਤੇ ਪੈਕੇਜ ਕੀਤੀ ਸੇਵਾ ਵੱਖਰੇ ਵਰਤੋਂਕਾਰ, ਪਾਥ ਜਾਂ ਸੰਰਚਨਾ ਫਾਈਲਾਂ ਵਰਤ ਸਕਦੀਆਂ ਹਨ। ਕਿਸੇ ਵਸਤੂ ਨੂੰ ਪੁਰਾਣਾ ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ ਪਤਾ ਕਰੋ ਕਿ ਕੋਈ ਹੋਰ Squid ਇੰਸਟੈਂਸ ਅਜੇ ਵੀ ਚੱਲ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ।

ਫਿਰ ਅਸਫਲ ਹੋ ਰਹੀ ਸਹੀ ਕਾਰਵਾਈ ਪੜ੍ਹੋ। PID ਗਲਤੀ ਸੰਰਚਿਤ PID ਟਿਕਾਣੇ ਅਤੇ ਇਸਦੀ ਮੂਲ ਡਾਇਰੈਕਟਰੀ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ। ਲਾਗ ਗਲਤੀ ਲਾਗ ਫਾਈਲ ਜਾਂ ਡਾਇਰੈਕਟਰੀ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ। ਕੈਸ਼ ਸ਼ੁਰੂਆਤ ਦੀ ਗਲਤੀ ਸਟੋਰੇਜ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ। shm_open ਗਲਤੀ ਨਾਮਿਤ ਸਾਂਝੀ ਮੈਮਰੀ ਵਸਤੂ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ ਅਤੇ ਪਰੋਸੈਸ ਉੱਤੇ ਲਾਗੂ ਸੁਰੱਖਿਆ ਨੀਤੀ ਵੀ ਸ਼ਾਮਲ ਹੋ ਸਕਦੀ ਹੈ।

ਹਰ ਸਰੋਤ ਲਈ ਲੋੜੀਂਦੀ ਰਨਟਾਈਮ ਪਹੁੰਚ ਦੀ ਤੁਲਨਾ ਇਸਦੇ ਮੌਜੂਦਾ ਮਾਲਕ ਅਤੇ ਮੋਡ ਨਾਲ ਕਰੋ। ਜੇ ਆਮ ਇਜਾਜ਼ਤਾਂ ਕਾਫ਼ੀ ਲੱਗਦੀਆਂ ਹਨ, ਤਾਂ ਸੰਬੰਧਿਤ SELinux ਜਾਂ AppArmor ਇਨਕਾਰ ਦੇ ਸਬੂਤ ਜਾਂਚੋ। ਸਿਰਫ਼ “Permission denied” ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਕਿਹੜੀ ਪਰਤ ਨੇ ਪਹੁੰਚ ਇਨਕਾਰ ਕੀਤੀ।

ਦੂਜੀ ਸਮੱਸਿਆ ਬਣਾਏ ਬਿਨਾਂ ਮਾਲਕੀ ਠੀਕ ਕਰੋ

ਰਨਟਾਈਮ ਖਾਤੇ ਨੂੰ ਇੰਸਟਾਲੇਸ਼ਨ ਦੀ ਸੇਵਾ ਸੰਰਚਨਾ ਨਾਲ ਮੇਲ ਕੇ ਰੱਖੋ। ਸਭ ਕੁਝ nobody ਉੱਤੇ ਬਦਲਣ ਨਾਲ ਸਹਾਇਕ ਪਹੁੰਚ ਟੁੱਟ ਸਕਦੀ ਹੈ ਅਤੇ ਸੇਵਾ-ਪ੍ਰਬੰਧਿਤ ਫਾਈਲਾਂ ਨਾਲ ਨਵੀਂ ਅਸੰਗਤੀ ਆ ਸਕਦੀ ਹੈ।

/dev/shm ਵਿੱਚ Squid ਵਰਗੀ ਦਿਖਣ ਵਾਲੀ ਹਰ ਵਸਤੂ ਮਿਟਾਉਣਾ ਵੀ ਚੰਗਾ ਪਹਿਲਾ ਕਦਮ ਨਹੀਂ ਹੈ। ਨਾਮਿਤ ਵਸਤੂ ਸਰਗਰਮ ਇੰਸਟੈਂਸ ਦੀ ਹੋ ਸਕਦੀ ਹੈ। ਲੋੜ ਪੈਣ 'ਤੇ ਸਫ਼ਾਈ ਪ੍ਰਭਾਵਿਤ ਸੇਵਾ ਬੰਦ ਹੋਣ 'ਤੇ ਪੁਸ਼ਟੀ ਕੀਤੇ ਛੱਡੇ ਗਏ ਸਰੋਤ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਣੀ ਚਾਹੀਦੀ ਹੈ, ਫਿਰ ਆਮ ਸੇਵਾ ਵਿਧੀ ਰਾਹੀਂ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਲਾਭਦਾਇਕ ਨਤੀਜਾ ਸੰਗਤ ਸ਼ੁਰੂਆਤ ਅਤੇ ਮਾਲਕੀ ਮਾਡਲ ਹੈ। ਗਲਤੀ ਦੇ ਅਲੋਪ ਹੋਣ ਤੱਕ root ਵਜੋਂ ਇੱਕ ਹੁਕਮ ਚਲਾਉਣਾ ਅਗਲੀ ਨਿਯਮਿਤ ਮੁੜ-ਸ਼ੁਰੂਆਤ ਨੂੰ ਬਿਲਕੁਲ ਉਸੇ ਸਮੱਸਿਆ ਨਾਲ ਛੱਡ ਸਕਦਾ ਹੈ।