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

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

ਸੈਸ਼ਨ ਕਟਣ ਨੂੰ ਅੰਡਰਲੇ ਕਟਣ ਤੋਂ ਵੱਖ ਕਰੋ

ਡਿਸਕਨੈਕਟ ਹੋਣ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਦੁਬਾਰਾ ਕਨੈਕਟ ਕਰੋ। ਉਸੇ ਨੈੱਟਵਰਕ 'ਤੇ, ਨਵੇਂ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਬਿਨਾਂ, ਕੁਝ ਸਕਿੰਟਾਂ ਵਿੱਚ ਵਾਪਸ ਆਉਣ ਵਾਲਾ ਟਨਲ ਮਰੇ ਅੱਪਲਿੰਕ, Wi-Fi ਰੋਮਿੰਗ ਜਾਂ ਕਨਸੈਂਟਰੇਟਰ ਦੇ ਅਕਿਰਿਆ ਟਾਈਮਆਊਟ ਨਹੀਂ, ਸਗੋਂ ਬੰਦ ਹੋਏ ਸੈਸ਼ਨ ਵਰਗੇ ਸਥਾਨਕ ਕਾਰਨ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। Connecting 'ਤੇ ਅਟਕਣ ਵਾਲਾ ਜਾਂ ਨੈੱਟਵਰਕ ਬਦਲਣ ਤੱਕ ਅਸਫਲ ਹੋਣ ਵਾਲਾ ਟਨਲ ਹੋਰ ਲੇਖ ਹੈ।

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

ਕਨੈਕਟ ਹੋਣ ਵੇਲੇ ਕਲਾਇੰਟ ਨੇ ਕੀ ਦਰਜ ਕੀਤਾ, ਵੇਖੋ

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

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਕਲਾਇੰਟ ਕੀ ਵੇਖ ਸਕਦਾ ਸੀ, ਸੂਚੀਬੱਧ ਕਰੋ:

who
w
last -n 10
sudo ls -l /run/utmp

who ਤੋਂ ਆਉਣ ਵਾਲੀ ਹਰ ਲਾਈਨ utmp ਵਿੱਚ ਇੱਕ ਵਰਤੋਂਕਾਰ ਪ੍ਰੋਸੈਸ ਐਂਟਰੀ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਸੈਸ਼ਨ ਦੋ ਵਾਰ ਦਿਖਦਾ ਹੈ, ਇੱਕ ਵਾਰ ਗ੍ਰਾਫਿਕਲ ਲੌਗਇਨ ਲਈ ਅਤੇ ਇੱਕ ਵਾਰ ਟਰਮੀਨਲ ਲਈ, ਦੋਵੇਂ ਐਂਟਰੀਆਂ ਕਨੈਕਟ ਹੋਣ ਵੇਲੇ ਮੌਜੂਦ ਸਨ ਅਤੇ ਦੋਵੇਂ ਉਮੀਦਵਾਰ ਹਨ।

utmp ਵਿੱਚੋਂ ਸਿਰਫ਼ ਆਪਣੀ ਐਂਟਰੀ ਹਟਾਓ

ਪ੍ਰਕਾਸ਼ਿਤ ਹੱਲ ਤੁਹਾਡੇ ਵਰਤਣ ਵਾਲੇ ਸੈਸ਼ਨ ਨੂੰ ਕਲਾਇੰਟ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ utmp ਵਿੱਚ ਅਦਿੱਖ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਛੋਟਾ C ਪ੍ਰੋਗਰਾਮ getutent() ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ, ਉਹ ਰਿਕਾਰਡ ਲੱਭਦਾ ਹੈ ਜਿਸਦਾ ut_line ਮਿਆਰੀ ਇਨਪੁੱਟ ਦੇ TTY ਦੇ ਬਰਾਬਰ ਹੈ, ਫਿਰ ਉਸ ਰਿਕਾਰਡ ਨੂੰ ਮੁੜ ਲਿਖਦਾ ਹੈ। ਕ੍ਰਮ ਜਾਣਬੁੱਝ ਕੇ ਹੈ: setutent(), ਐਂਟਰੀ ਪੜ੍ਹੋ, ਉਸਦਾ ut_id ਕਾਪੀ ਕਰੋ, ut_type ਨੂੰ DEAD_PROCESS 'ਤੇ ਸੈੱਟ ਕਰੋ, ਵਰਤੋਂਕਾਰ ਅਤੇ ਲਾਈਨ ਫੀਲਡ ਖਾਲੀ ਕਰੋ, pututline() ਨਾਲ ਵਾਪਸ ਲਿਖੋ, ਫਿਰ endutent()।

ਇਸਨੂੰ ਕੰਪਾਇਲ ਕਰੋ, ਫਿਰ ਕਲਾਇੰਟ ਸ਼ੁਰੂ ਕਰਨ ਵਾਲੇ ਸ਼ੈੱਲ ਤੋਂ root ਵਜੋਂ ਚਲਾਓ:

sudo ./utmpremove && /opt/cisco/anyconnect/bin/vpn -s connect vpn.example.edu

ਔਜ਼ਾਰ ਕੁਝ ਨਹੀਂ ਕਰਦਾ ਦੀਆਂ ਜ਼ਿਆਦਾਤਰ ਰਿਪੋਰਟਾਂ ਦਾ ਕਾਰਨ ਦੋ ਅਸਫਲਤਾ ਢੰਗ ਹਨ। ਇਹ ਮਿਆਰੀ ਇਨਪੁੱਟ ਨਾਲ ਜੁੜੇ TTY 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਟਰਮੀਨਲ ਤੋਂ ਬਿਨਾਂ ਸਕ੍ਰਿਪਟ ਜਾਂ ਕ੍ਰੋਨ ਜੌਬ ਤੋਂ ਚਲਾਉਣ 'ਤੇ ਮਿਲਾਉਣ ਲਈ ਕੁਝ ਨਹੀਂ ਬਚਦਾ। ਅਤੇ /run/utmp ਆਮ ਵਰਤੋਂਕਾਰਾਂ ਲਈ ਲਿਖਣਯੋਗ ਨਹੀਂ, ਇਸ ਲਈ root ਤੋਂ ਬਿਨਾਂ ਚਾਲ ਐਗਜ਼ਿਟ ਸਥਿਤੀ ਵੇਖੇ ਬਿਨਾਂ ਚੁੱਪਚਾਪ ਅਸਫਲ ਹੁੰਦੀ ਹੈ।

ਟਨਲ ਬੰਦ ਹੋਣਾ ਸਹਿੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਜਾਂਚੋ

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

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

utmp ਮੁੜ ਲਿਖਣਾ ਗਲਤ ਜਵਾਬ ਕਦੋਂ ਹੁੰਦਾ ਹੈ

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

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

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

ਸੰਬੰਧਿਤ ਲੇਖ