скриптовая обвязка для xauth

выкинь freenx и поставь x2go

Спасибо, думаю надо переходить с freenx, но сейчас пока надо работать с ним.

Столкнулся с такой трудностью: если в терминальной сессии на freenx сервере сделать в терминале sudo reboot, то в домашнем каталоге пользователя остается файл .Xauthority размера 0.

файл с хозяином root? У тебя что-то с правами, дай поподробнее информацию. Лечить надо болезнь, а не симптомы.

нет, хозявин тот же самый, кто сессию пользовал и чей каталог home.

ls -l /home/хозявин/.Xauthority

сперва вот он 174 байтика, а после запуска NX Clienta происходит облом NX> 596 Session startup failed. и размер его становится 0, а остальные атрибуты те же (ну время ещё изменено, так он и создается заново, вероятно..)

очевидно, эта программа смогла создать файл, но не смогла его расширить (запись с O_APPEND). Такое бывает

1. при нехватке места

2. при запрете права записи в файл (-w). Т.к. права 0600, то возможно программа работает от какого-то другого юзера.

PS:

Не работает, и мне не хватает компетенции разобраться почему. Должна прозрачно возвращать все то же самое, что возвращает xauth, и статус возврата сохранять. Тогда кажись никто не заметит подмены и вызов пройдет прозрачно.

не работает наверное потому, что у вас условия не в том порядке, надо

if [ -f "$xauth_cookie" ] && [ ! -s "$xauth_cookie" ];

exit $?

а этого не нужно, возвращается код возврата последней команды.

очевидно, эта программа смогла создать файл, но не смогла его расширить (запись с O_APPEND)

Ещё такое бывает, когда программа файл создала, но писать чего-либо туда передумала и не убрала за собой. В логах сессии написано:

Info: Reconnection failed: NX Agent process could not be found.

не работает наверное потому, что у вас условия не в том порядке, надо

Они читаются в обратном порядке? Я думал, что слева направо: если файл существует, и если его размер равен нулю. Причем объединение по «и» допускает перемену мест операндов в классической булевой логике ... спасибо, понятно, что есть разница.

а этого не нужно, возвращается код возврата последней команды

Вот похоже перемудрил я, попробую без «exit»...

Ещё такое бывает, когда программа файл создала, но писать чего-либо туда передумала и не убрала за собой.

так не бывает. Точнее бывает, если ей kill -9 послали, или сегфолт замучил.

что логично, ибо комп был перегружен экстренно

ну не так уж и экстренно. Сейчас посмотрел в слаке, она сначала всем SIGTERM посылает, и ждёт 5 секунд. А уж потом начинает долбить SIGKILL'ом. ЕМНИП в deb&rh сделано примерно также. На SIGTERM процессы _должны_ адекватно реагировать, и удалять недоделанные файлы. Особенно такие. Может у вас почему-то эта программа не может завершиться нормально?

Они читаются в обратном порядке? Я думал, что слева направо: если файл существует, и если его размер равен нулю. Причем объединение по «и» допускает перемену мест операндов в классической булевой логике ...

они читаются слева направо. Но там ленивая(lazy) AND. Т.е. если первое условие НЕ сработало, то второе она и проверять не будет. Впрочем, в данном случае это вроде-бы одно и то же(но кто его знает? это ваш man test надо смотреть)

В классической булевой алгебре операнды вычисляются СРАЗУ. А в компьютере — по очереди (или тоже сразу, и получаются гонки).

попробую без «exit»...

вроде-бы и с exit должно работать. Но я не уверен в вашей версии шелла.

Стал отлаживать скрипт, много всего вылезло ... но

• $XAUTHORITY указывала не в "$HOME"/.Xauthority и при этом была определена и вполне конкретна (нельзя тупо передирать из интернета чей-то код)
• тупо ошибка в 4-ой строке:

  "then then "

Проблема решена. Хотел найти ссылку на тех хороших людей, которые отметили этот баг, но увы интернет большой, как найдешь, так и потеряешь. Итоговая версия обвязки:

#!/bin/bash
loc_xauth_cookie="$HOME"/.Xauthority;
if [ ! -s "$loc_xauth_cookie" ] && [ -f "$loc_xauth_cookie" ]; then
 rm -f "$loc_xauth_cookie";
fi
/usr/bin/xauth "$@"

COMMAND_XAUTH=/etc/nxserver/xauth_nx

emulek

Что-то я гляжу в книгу вижу фигу :) условия и впрямь записаны неверно, сперва, чтобы существовал, а потом не size. Но я записал все наоборот, потому как отрицание правильно поставить не смог :) сейчас уже вспоминаю ...

На SIGTERM процессы _должны_ адекватно реагировать, и удалять недоделанные файлы. Особенно такие. Может у вас почему-то эта программа не может завершиться нормально?

об этом писали и это баг, может она от виндового клиента реакции быстрой ждет и поэтому попадает под kill.

условия и впрямь записаны неверно, сперва, чтобы существовал, а потом не size. Но я записал все наоборот, потому как отрицание правильно поставить не смог

в принципе -s это если существует И не пуст. А ! -s это если НЕ существует ИЛИ пуст. Первое условие ложно тогда, и только тогда, когда файл существует И не пуст. В этом случае файл НЕ стирается. Далее работает второе, и файл НЕ стирается когда файл не существует.

Ну а вообще ленивая логика работает как обычная, если нет побочных эффектов и гонок. (что кстати с файлами бывает, ибо файл может удалится очень неудачно МЕЖДУ условиями)