Дублювати псевдо термінали в linux

7

На полі Redhat [Red Hat Enterprise Linux AS випуск 4 (Nahant Update 3)]

Часто ми помічаємо, що до однієї і тієї ж псевдотерміналу призначаються дві людини. Наприклад:

$who am i
user1 pts/4        Dec 29 08:38 (localhost:13.0)
user2 pts/4        Dec 29 09:43 (199.xxx.xxx.xxx)
$who -m
user1 pts/4        Dec 29 08:38 (localhost:13.0)
user2 pts/4        Dec 29 09:43 (199.xxx.xxx.xxx)
$whoami
user2

Це викликає проблеми у сценарії, тому що "who am i" повертає два рядки. Я знаю, що існують відмінності між цими двома командами, і, очевидно, ми можемо змінити сценарій, щоб усунути проблему. Але це все ще турбує мене, що два користувачі повертаються з тим же терміналом. Ми підозрюємо, що це може бути пов'язано з мертвими сесіями. Чи може хто-небудь пояснити, чому призначаються два (не єдині) числа очків і / або як це можна запобігти в майбутньому?

linux terminal

— bobtheowl2
джерело

1

Ви пробували з новою версією Red Hat? 4.3 є досить старим, останній 4.x-реліз - 4.8. Крім того, Red Hat 5 знаходиться у версії 5.4, що є великим кроком вперед. Якщо ви хочете спробувати нову версію без проблем з купівлею Red Hat, ви можете спробувати CentOS, який є двійковим сумісним з Red Hat.

— Jimmy Hedman
джерело

Домовилися, але в нашому корпоративному середовищі його більше залучають. У нас заплановано оновлення, але це ще є вихід. Ми помітили, що між різними * nix системами те, хто -m діяв теж.

— bobtheowl2

1

Рекомендується оновити сервер.

Якщо це не так, ви можете оновити деякі програми, а не інші. Які компоненти, і наскільки далеко їх модернізувати, "залишилися як вправа для студента".

Спочатку потрібно виконати деякі тести, щоб дізнатися, яку програму емулятора терміналу використовують люди, коли це відбувається. Це Xterm? Якщо так, зверніться до "Записок до випуску Red Hat Enterprise Linux 3" - http://mirror.centos.org/centos/3/docs/release-notes/as-amd64/RELEASE-NOTES-U8-x86_64-en.html

Там ви знайдете виправлення помилки для xterm, в якому просто сказано: "не пишіть подвійний запис utmp"

Так що це привело б мене до припущення, ви, ймовірно, потрібно оновити xterm принаймні xterm-179-6.EL3 (не запитайте мене, чому номер версії говорить EL3, я поняття не маю)

Сподіваюся, що це допомагає!
-pbr

— pbr
джерело

Це звучало добре, поки я не побачив, що у нас є xterm-192-1. Але оскільки обидві користувачі, які ображаються [ті, хто з'являються на чужих людей, які використовують xterms, сильно використовують xterms, і я не помітив, що це відбувається з іншою групою, вона все одно звучить так, ніби вона може бути пов'язана з xterm.

— bobtheowl2

Прокляття. Хоча я прибив це для вас. Можливо, я зробив; можливо, ці користувачі працюють з xterm, який знаходиться в іншому каталозі 'bin'? (Тобто ви впевнені, що вони запускають вашу програму xterm системи?) Спробуйте наступним чином: 'sudo updatedb' (перейдіть на обід), потім 'sudo locate xterm | grep bin'. Це не надійний спосіб знайти КОЖНОГО виконуваного файлу з іменем xterm у вашій системі, але він буде працювати набагато швидше, ніж альтернатива - 'sudo find / -name xterm -executable -print'. Спробуйте цю останню команду, лише якщо підхід locate / grep не виявляє будь-які «нечесні» версії xterm.

— pbr

"xterm-179-6.EL3", ймовірно, є "Enterprise Linux 3" і може бути більш пізньою версією xterm, або такою, яка має деякі більш конкретні речі, необхідні для RHEL.

— Trevoke

bobtheowl2 - не чули від вас - ви шукали вашу систему, щоб побачити, чи були інші Xterm виконувані файли, встановлені в іншому місці вашої системи? Тільки тому, що ваш первинний пакет xterm становить 192-1, це не означає, що де-небудь не може бути старих виконуваних файлів в іншому каталозі.

— pbr

1

Я не можу відтворити цю поведінку тут - все, що я роблю, вичищає utmp - але оновлення utmp здійснюється за допомогою допоміжної програми utempter, у /usr/lib/utempter, який називається xterm, так що якщо xterms з певних причин загинув у кам'яному режимі (наприклад, вичерпана віртуальна пам'ять), можливо, він не отримає шанс прибрати.

Зауважте також, що в ній було виправлено вразливість безпеки http://rhn.redhat.com/errata/RHSA-2004-174.html Хоча, мабуть, навряд чи цей користувач викликає дисфункції, навмисно використовуючи це.

Перевірте, чи можна відтворити поведінку, запустивши xterm у фоновому режимі і вбивши його, не надаючи йому можливості очистити utmp:

$ who
$ xterm &
[1] 6229
$ who
$ kill -9 6229
$ who

І одна теорія вуду: я це помічаю xterm має налаштування, щоб зробити поведінку utmp більш обережною. Зазвичай він увімкнено за замовчуванням і вимкнено шляхом введення

XTerm*ptyHandshake:     false

в ~/.Xresources або загальносистемний /etc/X11/Xresources/xterm. Навряд чи це буде, але просто думка.

Одним з обхідних шляхів може бути переконати або змусити користувачів використовувати інший емулятор терміналу X, наприклад rxvt, менша заміна, яка відповідає існуючим налаштуванням xterm, не включає функцію емуляції графіки графіки Tektronix 4014 і використовує значно менше пам'яті для запуску.

— martinwguy
джерело

Користувачі, з якими це відбувається, безумовно не викликають зловмисності. Я також не зміг відтворити його. Я помітив, що навіть я [тільки за допомогою putty / ssh] мав старий вхід utmp на початку цього тижня. Це збіглося з моїм підключенням VPN підключення, і мені довелося вбити моє вікно putty і знову відкрити. Звичайно, сьогодні я не можу його відтворити. Я не був обізнаний з фундаментом, але це схоже на правильний напрямок.

— bobtheowl2