Процесс зависает до завершения с Ubuntu 18.04

Question

Процесс зависает до завершения с Ubuntu 18.04

При использовании ABAQUS 6.14 (но также и ABAQUS 2018) в Ubuntu 18.04 кажется, что все работает нормально, кроме завершения standard процесс (процесс начался при выполнении неявного анализа - если вы не знакомы с этим, это не имеет значения).

Анализ действительно работает так же, как можно увидеть в файле журнала (.sta файл, для тех, кто знаком с abaqus) сообщение THE ANALYSIS HAS COMPLETED SUCCESSFULLY, Выходная база данных содержит результаты анализа. Однако после завершения анализа процесс standard остается в спящем состоянии, используя 0% ЦП и сохраняя тот же объем ОЗУ, что и при работе.

От strace Я получил:

[pid 23191] close(8)                    = 0
[pid 23185] <... select resumed> )      = 0 (Timeout)
[pid 23185] select(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=50000} <unfinished ...>
[pid 23193] <... select resumed> )      = 0 (Timeout)
[pid 23193] futex(0x7f3acd917db0, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
[pid 23191] futex(0x7f3acd917db0, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
[pid 23193] <... futex resumed> )       = 0
[pid 23191] <... futex resumed> )       = -1 EAGAIN (Resource temporarily unavailable)
[pid 23191] futex(0x7f3acd917db0, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 23193] select(7, [4 5 6], NULL, NULL, {tv_sec=0, tv_usec=20000} <unfinished ...>
[pid 23191] munmap(0x7f3ab130b000, 327680) = 0
[pid 23191] munmap(0x7f3ab136b000, 1114112) = 0
[pid 23191] munmap(0x7f3ab16db000, 1114112) = 0
[pid 23191] munmap(0x7f3ab0fbb000, 1114112) = 0
[pid 23191] munmap(0x7f3ab0ddb000, 1114112) = 0
[pid 23191] munmap(0x7f3ab0a0b000, 1114112) = 0
[pid 23191] munmap(0x7f3ab03fb000, 1114112) = 0
[pid 23191] munmap(0x7f3ab050b000, 1114112) = 0
[pid 23191] munmap(0x7f3ab00cb000, 1114112) = 0
[pid 23191] munmap(0x7f3ab02eb000, 1114112) = 0
[pid 23191] munmap(0x7f3ab14eb000, 1114112) = 0
[pid 23191] futex(0x7f3ab8a5dd44, FUTEX_WAIT_PRIVATE, 8, NULL) = -1 EAGAIN (Resource temporarily unavailable)
[pid 23191] futex(0x7f3ab8a5dd44, FUTEX_WAIT_PRIVATE, 12, NULL <unfinished ...>
[pid 23193] <... select resumed> )      = 0 (Timeout)
[pid 23193] select(7, [4 5 6], NULL, NULL, {tv_sec=0, tv_usec=20000}) = 0 (Timeout)
[pid 23193] select(7, [4 5 6], NULL, NULL, {tv_sec=0, tv_usec=20000} <unfinished ...>
[pid 23185] <... select resumed> )      = 0 (Timeout)
[pid 23185] select(10, [5 6 8 9], NULL, NULL, {tv_sec=0, tv_usec=20000} <unfinished ...>
[pid 23193] <... select resumed> )      = 0 (Timeout)
[pid 23193] select(7, [4 5 6], NULL, NULL, {tv_sec=0, tv_usec=20000} <unfinished ...>
[pid 23185] <... select resumed> )      = 0 (Timeout)
[pid 23185] select(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=50000} <unfinished ...>
[pid 23193] <... select resumed> )      = 0 (Timeout)
[pid 23193] select(7, [4 5 6], NULL, NULL, {tv_sec=0, tv_usec=20000}) = 0 (Timeout)
[pid 23193] select(7, [4 5 6], NULL, NULL, {tv_sec=0, tv_usec=20000} <unfinished ...>
[pid 23185] <... select resumed> )      = 0 (Timeout)
[pid 23185] select(10, [5 6 8 9], NULL, NULL, {tv_sec=0, tv_usec=20000} <unfinished ...>
[pid 23193] <... select resumed> )      = 0 (Timeout)
[pid 23193] select(7, [4 5 6], NULL, NULL, {tv_sec=0, tv_usec=20000} <unfinished ...>
[pid 23185] <... select resumed> )      = 0 (Timeout)
[pid 23185] select(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=50000} <unfinished ...>
[pid 23193] <... select resumed> )      = 0 (Timeout)
[pid 23193] select(7, [4 5 6], NULL, NULL, {tv_sec=0, tv_usec=20000}) = 0 (Timeout)
[pid 23193] select(7, [4 5 6], NULL, NULL, {tv_sec=0, tv_usec=20000}) = 0 (Timeout)
[pid 23193] select(7, [4 5 6], NULL, NULL, {tv_sec=0, tv_usec=20000} <unfinished ...>

Как если бы два процесса были в тупиковом состоянии. Более того, команды

pid -p 7002

а также

pid -p 7010

сделать пустой вывод. Dirs /proc/7002 а также /proc/7010 не существует.

Выполняются только связанные с abaqus процессы

david  6995  0.0  0.1 295428 51388 pts/0    S    17:00   0:00 /opt/abaqus/6.14-1/code/bin/python /opt/abaqus/6.14-1
david  6998  0.0  0.2 368744 97948 pts/0    S    17:00   0:00 /opt/abaqus/6.14-1/code/bin/python std_inst.com
david  7001  0.1  0.0 122076 20096 pts/0    Sl   17:00   0:03 /opt/abaqus/6.14-1/code/bin/eliT_DriverLM -job std_in
david  7008  0.4  0.5 735812 185364 pts/0   Sl   17:00   0:07 /opt/abaqus/6.14-1/code/bin/standard -standard -acade

На Ubuntu 16.04 точно такая же версия работает как шарм. Здесь то же самое strace в Ubuntu 16.04 (с той же версией ядра, что и у меня 18.04, т.е. 4.15.0-29):

3890  close(8)                          = 0
3892  <... select resumed> )            = 0 (Timeout)
3892  futex(0x7f29e43e1db0, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
3890  futex(0x7f29e43e1db0, FUTEX_WAKE_PRIVATE, 1) = 0
3892  <... futex resumed> )             = -1 EAGAIN (Resource temporarily unavailable)
3892  futex(0x7f29e43e1db0, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
3890  futex(0x7f29e43e1db0, FUTEX_WAKE_PRIVATE, 1) = 0
3892  <... futex resumed> )             = -1 EAGAIN (Resource temporarily unavailable)
3892  futex(0x7f29e43e1db0, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
3890  futex(0x7f29e43e1db0, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
3892  <... futex resumed> )             = 0
3890  <... futex resumed> )             = -1 EAGAIN (Resource temporarily unavailable)
3890  futex(0x7f29e43e1db0, FUTEX_WAKE_PRIVATE, 1) = 0
3892  select(7, [4 5 6], NULL, NULL, {0, 20000} <unfinished ...>
3890  munmap(0x7f29c7adb000, 327680)    = 0
3890  munmap(0x7f29c7b3b000, 1114112)   = 0
3890  munmap(0x7f29c7eab000, 1114112)   = 0
3890  munmap(0x7f29c778b000, 1114112)   = 0
3890  munmap(0x7f29c75ab000, 1114112)   = 0
3890  munmap(0x7f29c71db000, 1114112)   = 0
3890  munmap(0x7f29c6bcb000, 1114112)   = 0
3890  munmap(0x7f29c6cdb000, 1114112)   = 0
3890  munmap(0x7f29c689b000, 1114112)   = 0
3890  munmap(0x7f29c6abb000, 1114112)   = 0
3890  munmap(0x7f29c7cbb000, 1114112)   = 0
3890  exit_group(0)                     = ?
3891  +++ exited with 0 +++
3893  +++ exited with 0 +++
3892  +++ exited with 0 +++
3890  +++ exited with 0 +++
3880  <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 3890
3880  --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3890, si_uid=1000, si_status=0, si_utime=107, si_stime=7} ---

У кого-нибудь есть хорошая идея, как это решить? Или в каком направлении мне следует продолжить расследование.

6

18.04 process strace

Источник

David 03 авг '18 в 15:43

3 ответа

Другие вопросы по тегам 18.04 process strace

A. Bernath 19 янв '19 в 12:57 2019-01-19 12:57 · Answer 1 · 2019-01-19 12:57

Я нашел решение, которое позволяет обойти тупик, используя контейнер для сингулярности, предложенный Уиллом Фернассом здесь: http://learningpatterns.me/posts-output/2018-01-30-abaqus-singularity/

Хотя это немного сложно, во-первых, при правильной настройке он работает как шарм. Я изменил мои псевдонимы для abaqus в моей хост-системе (Manjaro/Arch linux) так, чтобы они указывали на установку в контейнере singularity и выполняли команду в среде контейнеров. Однако, так как мне нужен Intel Fortran Compiler, я сгенерировал базовый контейнер centos 7 и впоследствии изменил его для установки компиляторов и abaqus (в данном случае v2019) вместо использования сценария.def, предложенного Уиллом Фернассом.

Это требует некоторого времени для установки, но теперь у меня есть образ контейнера, с которым я могу работать на любой системе, которая работает с особенностями, что довольно приятно:)

РЕДАКТИРОВАТЬ: Я также тестировал копирование рабочей установки в более новую систему Linux (и избегая новой установки abaqus), я могу подтвердить, что в моем случае это не сработало (установка CentOS 7 скопирована в систему Manajaro).

Charles Jekel 22 янв '19 в 15:27 2019-01-22 15:27 · Answer 2 · 2019-01-22 15:27

Я хотел бы представить мою работу по этому вопросу. Я сделал оболочку Python для решателя abq2018, которая проверяет файл.sta на полноту. Как только файл.sta будет завершен, любой процесс с именем standard будет убит. Я обнаружил, что решатель завершает работу изящно, когда стандарт убит и анализ завершен.

Эта работа не является идеальным решением. Текущие проблемы с этой работой вокруг:

не может заменить решатель abq2018 напрямую
не будет работать из графического интерфейса, должен быть запущен из оболочки
только анализирует задание = аргумент
вы можете запустить только один анализ за раз, так как все стандартные процессы убиты
abq будет висеть вечно, если файл.sta не создан или не изменен

Как использовать этот обходной путь:

Создайте файл Python с именем abq. Код для abq подробно описан ниже. Если вы используете решатель, отличный от abq2018, замените строку cmd = 'abq20xx.. на используемый вами решатель.
Сделайте abq исполняемым и доступным по вашему пути. Я поместил abq в папку команд Abaqus, затем запустил chmod +x abq
Запустите стандартное задание Abaqus, выполнив abq job=Job-1, Это выполнит Job-1.inp, затем убьет стандартный решатель, как только Job-1.sta будет завершен.

Код для ABQ ниже

#!/usr/bin/python
import subprocess
import sys
import time
arguments = sys.argv
jobname = arguments[1].split('job=')[-1]
cmd = 'abq2018 cpus=4 ask_delete=OFF background job=' + jobname
p = subprocess.call(cmd, shell=True)

complete = False
termination_criteria = [' THE ANALYSIS HAS COMPLETED SUCCESSFULLY\n',
                        ' THE ANALYSIS HAS NOT BEEN COMPLETED\n']

while complete is False:
    # wait every 5 seconds
    time.sleep(5)
    try:
        with open(jobname + '.sta', 'r') as f:
            last = f.readlines()[-1]
            if last in termination_criteria:
                # this will kill any process named standard
                subprocess.call('pgrep standard | xargs kill', shell=True)
                complete = True
    except IOError:
        # model.sta has been deleted or doesn't exist
        # try again in 5 seconds
        time.sleep(5)

JoKalliauer 01 окт '20 в 20:29 2020-10-01 20:29 · Answer 3 · 2020-10-01 20:29

В этом месяце система Dassaults опубликовала исправление ошибки:

Вам необходимо обновить до Abaqus 2018 к Abaqus 2018-HF16с https://software.3ds.com/ более подробную информацию можно найти на https://github.com/willfurnass/abaqus-2017-centos-7-singularity/issues/5#issue-713025844

Пробовал с обновлением Abaqus 2020 к Abaqus 2020-HF5 и он работал как для Ubuntu 20.04, так и для Fedora 32.

leileilei 07 ноя '18 в 18:38 2018-11-07 18:38 · Answer 4 · 2018-11-07 18:38

Я столкнулся с этой проблемой и в Linux mint 19. Abaqus 6.14-5 установлен в Linux Mint 19. Он не может быть завершен автоматически, но в виде файла.sta, анализ завершен. Я думаю, что эта проблема связана с ядром. Кстати, вы найдете какие-либо решения сейчас?

0

Источник

leileilei 07 ноя '18 в 18:38