Почему команда, запущенная с помощью nohup, не может записать файл после выхода пользователя из системы?

Почему команда, запущенная с помощью nohup, не может записать файл после выхода пользователя из системы?

Я использую nohup для запуска Matlab и выполнения скрипта, который требует чтения и записи некоторых заданных файлов.

nohup matlab -nojvm -nodisplay -r 'MyScript'&

Это работает гладко, пока я вошел в систему, но как только я выхожу из системы и снова вхожу, я вижу, что мой процесс matlab больше не выполняется. После проверки файла nohup.out я нахожу следующее сообщение об ошибке:

Unable to write file $HOME/matlab/my_mat_file.mat: permission denied

Кажется, как только я выхожу из системы, владелец процесса matlab меняется, и у него больше нет доступа к моим файлам. Как предотвратить возникновение этой ошибки без изменения прав доступа к файлам, например, предоставив права на запись всем?

Это сообщение об ошибке также появляется при использовании GNU-screen. Если я запущу ls -al $HOMEсеанс GNU-screen перед выходом из системы, то у меня будет

команда перед выходом из системы

Я отсоединяюсь от сеанса GNU-screen, выхожу из системы, вхожу в систему и снова подключаюсь к сеансу screen, чтобы обнаружить, что я потерял доступ к файлам, к которым у меня был доступ внутри screen. Вывод ls -al $HOMEтеперь такой:

команда после выхода из системы

Интригует, не правда ли?

решение1

Это связано с аутентификацией.

Я начну с некоторых концепций по билетам и токенам и того, как система аутентификации Kerberos и AFS их используют. К концу ответ на мой вопрос будет ясен, мне не разрешено писать в файл просто потому, что мой токен AFS был удален при выходе из системы. Тем не менее, решение моей проблемы состояло в том, чтобы включить в скрипт Matlab несколько строк, которые определяют, существует ли токен или нет, создавая его в случае его отсутствия. Как именно это было сделано, завершает ответ.

Аутентификация

Предоставление распределенной файловой системы, доступной в любой точке мира, подразумевает надежную систему безопасности. Вот почему AFS имеет надежную систему аутентификации, интегрированную с системой аутентификации Kerberos.

Аутентификация в AFS решается с помощью токена. Токены предоставляют пользователям доступ к данным в течение всего срока их действия. Во многих случаях обработка токенов происходит незаметно, не требуя вмешательства пользователя. Однако пользователь может в любой момент времени перечислить токены, выпущенные на его имя, используяtokens

username@machine00 ~ $ tokens

Tokens held by the Cache Manager:

User's (AFS ID xxxxx) tokens for [email protected] [Expires Mar 20 05:10]
   --End of list--

Токены AFS получаются из идентификационного билета Kerberos. Подобно токенам, билеты Kerberos также идентифицируют пользователя. При использовании системы аутентификации Kerberos KDC (центр распространения ключей) выдает пользователю начальный билет, называемый билетом на выдачу билетов. Этот первый билет однозначно идентифицирует пользователя и позволяет ему получать определенные билеты, необходимые для дальнейших услуг, таких как токены AFS. Фактически, вы можете использовать билет Kerberos напрямую, так как служба AFS имеет идентификационный токен AFS.

В большинстве случаев билет Kerberos' ticket-granting автоматически получается во время входа пользователя в систему. То же самое происходит и с начальным токеном AFS. Как и токены, обработка билетов Kerberos в большинстве случаев невидима для пользователя, но вы можете перечислить выданные билеты, используяklist

username@machine00 ~ $ klist
Credentials cache: FILE:/tmp/krb5cc_V16088
        Principal: [email protected]

  Issued           Expires          Principal                 
Mar 19 19:10:11  Mar 20 05:10:11  krbtgt/[email protected]
Mar 19 19:10:11  Mar 20 05:10:11  afs/[email protected]   
username@machine00 ~ $

кэш учетных данных — это местоположение файла, в котором находятся билеты. Principal — это идентификатор пользователя, который в основном получается из комбинации имени пользователя и домена области Kerberos. Обратите внимание, что область Kerberos обычно указывается заглавными буквами и чувствительна к регистру. Далее следует список выданных билетов с соответствующими датами выдачи и истечения срока действия. В этом случае первый билет ( krtbg) соответствует билету на выдачу билетов в области KERBEROS.REALM.DOMAIN, а второй соответствует токену AFS в ячейке afs your.system.domain(которая обычно имеет то же имя, что и домен, в котором ее можно найти). Другие билеты Kerberos могут отображаться в списке, если они были запрошены.

Обновление токена

Когда срок действия токена AFS истекает, доступ к учетной записи AFS становится невозможным. Симптомы того, что произошло такое событие, различаются в зависимости от ОС, однако в Unix/Linux вы обычно получаете сообщение об отказе в доступе при попытке доступа к файлам:

username@machine00 ~ $ ls
ls: .: Permission denied

Когда токен истекает, вам нужно его обновить. Самый простой способ сделать это — выйти из системы и войти снова, поскольку в большинстве случаев обновление токена происходит автоматически при входе в систему. Но оказывается, что иногда выход из системы невозможен, особенно если вы работаете с чем-то, из чего не хотите выходить, что как раз и происходит.

Альтернативным решением для обновления билета является последовательное использование kinitи aklog. Первая из этих команд ( kinit), которая требует ваш пароль, позволяет пользователю повторно аутентифицироваться и обновить билет на выдачу билетов. Следующая aklogкоманда позволяет вам получить токен AFS из билета Kerberos. Обратите внимание, что kinitпытается получить билет для принципала и области по умолчанию. В случае, если они не определены или если пользователь использует другое имя пользователя во время запроса билета, kinitследует использовать как kinit <principal>@<realm>, например:

username@machine00 ~ $ kinit [email protected]
[email protected]'s Password: 
username@machine00 ~ $

Противоположностью aklogявляется unlog, который удаляет токен AFS. Соответственно, kdestroyудаляет файл билетов, удаляя все билеты Kerberos.

Как это спасло ситуацию и помогло мне полюбить своих друзей и семью

Как я уже говорил в начале, знание этих концепций помогло мне лучше понять, что происходит с моей сессией Matlab. После выхода из системы мой токен AFS больше не был там, и мои запущенные процессы больше не имели разрешения на запись в мой том afs. Поскольку на данный момент я заинтересован только в том, чтобы гарантировать, что мой скрипт Matlab продолжит работать, читая и записывая файлы даже после выхода из системы, я был осторожен и включил тест на токен AFS перед любым доступом к тому AFS

ticket_status = unix('klist -s');
if ticket_status ~= 0,
   unix 'kinit [email protected] <<< "password"';
   unix  aklog
end

Как я уже сказал, это входит в скрипт matlab, и я поместил его перед любой saveили loadкомандами matlab. Код использует команду matlab unixдля запуска своих аргументов в оболочке Unix и возврата результатов. Команда Unix klist -sвыполняется klistмолча, но возвращает свой статус выхода. Мы проверяем статус выхода для учетных данных и запрашиваем новые, если они не существуют или устарели.

Связанный контент