VPN ਸ਼ੁਰੂ ਹੁੰਦਿਆਂ ਕਰਨਲ Oops: ਸੰਭਾਲਣ ਯੋਗ ਸਬੂਤ

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

ਆਖਰੀ ਲਾਈਨ ਨਹੀਂ, ਪਹਿਲਾ ਫਾਲਟ ਫੜੋ

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

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

ਕੋਈ ਵੀ ਪ੍ਰਤੀਕ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਬਿਲਡ ਤੈਅ ਕਰੋ

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

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

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

ਟ੍ਰਿਗਰ ਨੂੰ ਨੁਕਸ ਤੋਂ ਵੱਖ ਕਰੋ

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

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

ਜਾਂਚੋ ਕਿ ਸੰਭਾਲਕਰਤਾ ਅਸਲ ਵਿੱਚ ਕੀ ਵਰਤ ਸਕਦਾ ਹੈ

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

uname -r
cat /proc/sys/kernel/tainted
journalctl -k -b -1 --no-pager | sed -n '/BUG:/,/Call Trace/p'
dmesg -T | grep -A 40 'RIP:'

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

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