Pi ਤੇ VPN ਕਲਾਇੰਟ segfault? ਪਹਿਲਾਂ ਪ੍ਰਕਿਰਿਆ ਕੈਪਚਰ ਕਰੋ

ਤੁਸੀਂ ਕਲਾਇੰਟ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ, ਟਰਮੀਨਲ Segmentation fault (core dumped) ਛਾਪਦਾ ਹੈ, ਅਤੇ ਅਗਲਾ ਘੰਟਾ ਕਾਰਡ ਦੁਬਾਰਾ ਫਲੈਸ਼ ਕਰਨ ਵਿੱਚ ਲੱਗਦਾ ਹੈ। ਉਹ ਸੁਨੇਹਾ ਦੱਸਦਾ ਹੈ ਕਿ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਇੱਕ ਪਲ ਵਿੱਚ ਕਿਵੇਂ ਮਰੀ। ਇਹ ਨਹੀਂ ਕਹਿੰਦਾ ਕਿ ਬੋਰਡ ਖਰਾਬ ਹੈ, ਅਤੇ ਨਾ ਹੀ ਇਹ ਬਿਜਲੀ ਸਪਲਾਈ, ਸਟੋਰੇਜ ਜਾਂ ਇਮੇਜ ਨੂੰ ਬਰੀ ਕਰਦਾ ਹੈ।

ਸ਼ੈਲ ਵੱਲੋਂ ਛਾਪੀ ਲਾਈਨ ਤੋਂ ਉਸ ਦੇ ਪਿੱਛੇ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵੱਲ ਕੰਮ ਕਰੋ। ਲਾਹੇਵੰਦ ਤੱਥ ਇਹ ਹਨ ਕਿ ਕਿਹੜੀ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਫੇਲ੍ਹ ਹੋਈ, ਕਿਹੜੇ ਵਾਤਾਵਰਨ ਵਿੱਚ ਅਤੇ ਕਨੈਕਸ਼ਨ ਦੇ ਕਿਹੜੇ ਪੜਾਅ ਉੱਤੇ।

ਸ਼ੈਲ ਦੀ ਛਾਪੀ ਲਾਈਨ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

ਤੁਹਾਡੇ ਕਮਾਂਡ ਦਾ ਨਾਮ ਅਕਸਰ ਇੱਕ ਰੈਪਰ ਜਾਂ ਲਾਂਚਰ ਹੁੰਦਾ ਹੈ ਜੋ ਦੂਜੀ ਬਾਈਨਰੀ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਪੱਕਾ ਕਰੋ ਕਿ ਕਰਨਲ ਨੇ ਅਸਲ ਵਿੱਚ ਕਿਹੜੀ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਖਤਮ ਕੀਤੀ। ਪੂਰਾ ਪਾਥ, ਪੈਕੇਜ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਵਰਜ਼ਨ, ਆਰਕੀਟੈਕਚਰ, OS ਅਤੇ ਕਰਨਲ ਰਿਲੀਜ਼, ਇਸ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਵਾਲਾ ਖਾਤਾ ਅਤੇ ਸਹੀ ਸਮਾਂ ਲਿਖੋ। VPN ਨਾਮ ਵਾਲਾ ਸ਼ੈਲ ਕਮਾਂਡ ਸੌਖਿਆਂ ਸਹਾਇਕ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਰਿਕਾਰਡ ਉਸ ਸਹਾਇਕ ਦਾ ਨਾਮ ਲਵੇਗਾ। ਪਿਛਲੇ ਮਹੀਨੇ ਸਥਾਪਤ ਕੀਤੇ ਪੈਕੇਜ ਦੀ ਵਰਜ਼ਨ ਸਟ੍ਰਿੰਗ ਕਾਪੀ ਕਰਨ ਨਾਲ ਕੀ ਚੱਲਿਆ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਪਤਾ ਲੱਗਦਾ।

ਨੋਟ ਕਰੋ ਕਿ ਕ੍ਰੈਸ਼ ਤੋਂ ਠੀਕ ਪਹਿਲਾਂ ਕੀ ਹੋਇਆ: ਸਟਾਰਟਅੱਪ, ਪ੍ਰੋਫਾਈਲ ਪਾਰਸਿੰਗ, ਪ੍ਰਮਾਣੀਕਰਨ, ਜਾਂ ਅਜਿਹਾ ਸੈਸ਼ਨ ਜੋ ਪਹਿਲਾਂ ਹੀ ਟ੍ਰੈਫਿਕ ਲੰਘਾ ਰਿਹਾ ਸੀ। ਉਹ ਚਾਰ ਪੜਾਅ segfault ਸ਼ਬਦ ਨਾਲੋਂ ਕਿਤੇ ਵੱਧ ਖੋਜ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰਦੇ ਹਨ। ਉਸ ਘਟਨਾ ਦੇ ਆਸਪਾਸ ਦੀ ਛੋਟੀ ਲੌਗ ਵਿੰਡੋ ਰੱਖੋ, ਅਤੇ ਜਦੋਂ ਤੱਕ ਰਿਕਾਰਡ ਨਾ ਕਹੇ ਕਿ ਕਿਹੜੇ ਤਾਜ਼ਾ ਬਦਲਾਅ ਨੇ ਇਹ ਕੀਤਾ, ਅੰਦਾਜ਼ੇ ਛੱਡ ਦਿਓ।

ਪਤਾ ਕਰੋ ਕਿ ਮੈਮੋਰੀ ਇਮੇਜ ਮੌਜੂਦ ਹੈ ਜਾਂ ਨਹੀਂ

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

systemd ਦੇ ਕੁਲੈਕਟਰ ਵਾਲੇ ਸਿਸਟਮ ਵਿੱਚ, ਸਮਰਥਿਤ ਦ੍ਰਿਸ਼ ਸਟੋਰ ਕੀਤੇ ਰਿਕਾਰਡ ਨੂੰ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਅਤੇ ਸਮੇਂ ਨਾਲ ਜੋੜਦਾ ਹੈ। ਜਰਨਲ ਐਂਟਰੀ ਅਤੇ ਪੜ੍ਹਨਯੋਗ ਮੈਮੋਰੀ ਇਮੇਜ ਦੋ ਵੱਖਰੀਆਂ ਕਲਾਕ੍ਰਿਤੀਆਂ ਹਨ: ਰੱਖ-ਰਖਾਅ ਨੀਤੀ ਅਤੇ ਇਜਾਜ਼ਤਾਂ ਇੱਕ ਨੂੰ ਦੂਜੇ ਤੋਂ ਬਿਨਾਂ ਛੱਡ ਸਕਦੀਆਂ ਹਨ। ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਸੰਭਾਲਕਰਤਾ ਨੂੰ ਉਨ੍ਹਾਂ ਦੇ ਸਮਰਥਿਤ ਡਾਇਗਨੌਸਟਿਕ ਵਰਕਫਲੋ ਬਾਰੇ ਪੁੱਛੋ, ਕਿਉਂਕਿ ਕਿਸੇ ਹੋਰ ਬਿਲਡ ਜਾਂ ਹੋਰ ਲਾਇਬ੍ਰੇਰੀ ਸੈੱਟ ਤੋਂ ਬਣਿਆ ਟ੍ਰੇਸ ਆਮ ਤੌਰ 'ਤੇ ਉਨ੍ਹਾਂ ਦਾ ਸਮਾਂ ਬਰਬਾਦ ਕਰਦਾ ਹੈ।

sysctl kernel.core_pattern
ulimit -c
coredumpctl list --since "1 hour ago" --no-pager
coredumpctl info /usr/sbin/openvpn

ਉਹ ਪੜ੍ਹਤਾਂ ਉਸ ਮਸ਼ੀਨ ਉੱਤੇ ਦੁਹਰਾਓ ਜੋ ਅਸਲ ਵਿੱਚ ਕ੍ਰੈਸ਼ ਹੋਈ ਸੀ। ਨਵੀਂ ਸਥਾਪਨਾ ਉੱਤੇ ਉਹ ਕਰਨਾ ਕਿਸੇ ਨਾ ਪੁੱਛੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣਾ ਹੈ।

ਡੰਪ ਨੂੰ ਭੇਦ ਲੈ ਕੇ ਚੱਲਣ ਵਾਲੀ ਸਮੱਗਰੀ ਮੰਨੋ

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

ਜੇ ਸੰਭਾਲਕਰਤਾ ਟ੍ਰੇਸ ਮੰਗੇ, ਤਾਂ ਪੁੱਛੋ ਕਿ ਕਿਹੜੀ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਅਤੇ ਕਿਹੜੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਤੋਂ ਚਾਹੀਦਾ ਹੈ। ਜਿਸ ਦੇ ਫ੍ਰੇਮ ਰਿਪੋਰਟ ਕੀਤੇ ਬਿਲਡ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ, ਅਜਿਹਾ backtrace ਭਰੋਸਾ ਕਰਨਾ ਔਖਾ ਅਤੇ ਗਲਤ ਪੜ੍ਹਨਾ ਸੌਖਾ ਹੈ।

ਕੁਝ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਸਰੋਤ ਜਾਂਚੋ

ਸਥਾਪਨਾ ਦੇ ਮਾਲਕ ਰਾਹੀਂ ਪੈਕੇਜ ਦਾ ਸਰੋਤ ਅਤੇ ਫਾਈਲ ਦੀ ਅਖੰਡਤਾ ਪੜਤਾਲੋ, ਅਤੇ ਕਿਸੇ ਵੀ ਨਿਯੰਤਰਿਤ ਮੁਰੰਮਤ ਤੋਂ ਪਹਿਲਾਂ ਕੌਂਫਿਗਰੇਸ਼ਨ ਅਤੇ ਪਛਾਣ ਸਮੱਗਰੀ ਸੰਭਾਲੋ। ਸਿਰਫ਼ ਇਹ ਵੇਖਣ ਲਈ ਕਿ ਸਾਫ਼ ਸਥਾਪਨਾ ਬੂਟ ਹੁੰਦੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਸਬੂਤ ਦੀ ਇਕੱਲੀ ਕਾਪੀ ਨੂੰ ਨਾ ਮਿਟਾਓ। ਨਵੀਂ ਇਮੇਜ ਬੂਟ ਹੁੰਦੀ ਹੈ ਦਾ ਮਤਲਬ ਹੈ ਨਵੀਂ ਇਮੇਜ ਬੂਟ ਹੁੰਦੀ ਹੈ। ਇਹ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਪੁਰਾਣੀ ਵਿੱਚ ਖਰਾਬ ਪੈਕੇਜ, ਫੇਲ੍ਹ ਹੁੰਦਾ ਕਾਰਡ ਜਾਂ ਅਜਿਹੀ ਬਾਈਨਰੀ ਸੀ ਜੋ ਇਸ ਆਰਕੀਟੈਕਚਰ ਉੱਤੇ ਹਮੇਸ਼ਾ ਫਾਲਟ ਕਰਦੀ।

ਜੇ ਅਸੰਬੰਧਿਤ ਪ੍ਰੋਗਰਾਮ ਵੀ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ, ਜਾਂ ਸਿਸਟਮ ਸਟੋਰੇਜ, ਬਿਜਲੀ ਜਾਂ ਕਰਨਲ ਗਲਤੀਆਂ ਲੌਗ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹ ਨਿਰੀਖਣ ਪਲੇਟਫਾਰਮ ਜਾਂਚ ਲਈ ਰੱਖੋ। ਉਹ ਦਾਇਰਾ ਫੈਲਾਉਂਦੇ ਹਨ; ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੇ ਕਿ ਹਰ segfault ਫੇਲ੍ਹ ਹੋ ਰਹੀ RAM ਜਾਂ ਖਰਾਬ ਇਮੇਜ ਤੋਂ ਆਉਂਦਾ ਹੈ।

ਲਕਸ਼ਿਤ ਸੁਧਾਰ ਤੋਂ ਬਾਅਦ ਉਸੇ ਹਾਰਡਵੇਅਰ ਉੱਤੇ ਉਹੀ ਅਧਿਕ੍ਰਿਤ ਲਾਂਚ ਅਤੇ ਉਹੀ VPN ਕਾਰਵਾਈ ਦੁਹਰਾਓ। ਦੱਸੋ ਕਿ ਕਿਹੜੀ ਫੇਲ੍ਹਤਾ ਕਿਹੜੇ ਵਰਜ਼ਨ ਵਿੱਚ ਰੁਕੀ। ਸਿਰਫ਼ ਸਾਫ਼ ਬੂਟ ਕੋਈ ਨੁਕਸਦਾਰ ਹਿੱਸਾ ਨਹੀਂ ਪਛਾਣਦਾ ਅਤੇ ਅਗਲੀ ਹਾਰਡਵੇਅਰ ਖਰਾਬੀ ਦੀ ਭਵਿੱਖਬਾਣੀ ਵੀ ਨਹੀਂ ਕਰਦਾ।