2016-04-18 5 views
0

Я использую ниже код, чтобы открыть порт 80 на моем разъединяет:Fireware Ошибка на CentOS 7

sudo firewall-cmd --zone=public --add-port=80/tcp --permanent 

, но я получаю эту ошибку:

Traceback (most recent call last): 
    File "/bin/firewall-cmd", line 24, in <module> 
    from gi.repository import GObject 
    File "/usr/lib64/python2.7/site-packages/gi/__init__.py", line 37, in <module> 
    from . import _gi ImportError: /lib64/libgirepository-1.0.so.1: 
undefined symbol: g_type_class_adjust_private_offset 

Пожалуйста, помогите мне исправить. Благодаря!

+0

Представляется, что это ошибка в файле Shared-Object ... – linusg

+1

Что делает 'rpm -qf/lib64/libgirepository-1.0.so.1' output? Что относительно 'rpm -V $ (rpm -qf /lib64/libgirepository-1.0.so.1)'? –

+0

hi @ etan-reisner Результат: gobject-introspection-1.42.0-1.el7.x86_64' – binkute

ответ

0

У меня была такая же проблема на некоторых CentOS 7, VMV OpenVZ, которые были установлены без установленного firewalld. Просто установка firewalld пакет RPM не работает, так как при запуске, firewalld бы сказать:

# /usr/sbin/firewalld --nofork --nopid 
Traceback (most recent call last): 
    File "/usr/sbin/firewalld", line 132, in <module> 
    from firewall.server import server 
    File "/usr/lib/python2.7/site-packages/firewall/server/server.py", line 32, in <module> 
    from gi.repository import GObject, GLib 
    File "/usr/lib64/python2.7/site-packages/gi/__init__.py", line 37, in <module> 
    from . import _gi 
ImportError: /lib64/libgirepository-1.0.so.1: undefined symbol: g_type_class_adjust_private_offset 

После большой сделки faffing о, я обнаружил, что (по состоянию на июнь 2016 года) простого «ни обновления» достаточно, чтобы все это работало. Я не мудрее, какие пакеты на самом деле являются виновниками, но получить все в курсе, вероятно, хорошо.

+0

большое спасибо! – binkute

0

Итак, быстро исправим файл «/ bin/firewall-cmd» (или сделайте копию этого файла, затем отредактируйте копию), затем измените первую строку с «#!/Usr/bin/python - Es "на" #!/Usr/bin/python2 -Es ". В моей системе эта проблема, по-видимому, была вызвана тем, что кто-то установил python3, а затем модифицировал символическую ссылку для «/ bin/python», чтобы указать на python3, а не на 2. Предупреждение: для многих внутренних скриптов Linux требуется python2. Любой новый скрипт, требующий python3, должен объявить это в shebang (резкий удар) в строке 1. Кстати, я также видел, как python3 разорвал некоторые связанные с ним операции.

Смежные вопросы