2016-11-03 7 views
2

У меня возникли проблемы с ошибкой в ​​версии Fedora 24 Server. Служба Firewalld всегда запускается, даже если она отключена. Однако на рабочей станции он остается отключенным, как ожидалось.Отслеживание приглашения на службу systemd

Я посмотрел его и кто-то сталкивался с этой ошибки, а также: https://bugzilla.redhat.com/show_bug.cgi?id=1371122

Согласно одному из комментариев, услуга может быть запущена, если другой клиент DBus запрашивает. Поэтому мой лучший снимок заключается в том, что какое-то другое программное обеспечение в версии сервера запускает Firewalld, что может быть программой управления? Без понятия. Я догадался, что это был кокпит, поэтому я стер его с помощью dnf, но это был не ответ.

Я буду сообщать об этой ошибке после того, как напишу этот пост. Я хочу отслеживать, что/кто начинает службу. systemctl list-dependencies ничего не показывает. В нем говорится, что Firewalld даже не зависит от другого подразделения.

+0

Немного о теме, но можете ли вы пояснить, почему вы хотите отключить firewalld? Я собираю прецеденты. – mattdm

+0

Настройка брандмауэра @mattdm является утомительной для сервера в защищенной/частной сети (в моем случае, сети, которая даже не подключена к Интернету). Техники - немые/ленивые и даже не знают, как Linux. Если вы понимаете, о чем я. –

+0

Спасибо, но я знаю, как маскировать устройство. Я просто озадачен тем, что я могу отключить его на рабочей станции. Большая последовательность, поэтому простота. –

ответ

2

Немного вещей, которые вы можете сделать. Возможно, ваша служба началась с зависимости systemd. Довольно легко понять это. Просто выполните systemd show FIREWALLD.service и ищите WantedBy= или RequiredBy=. Если никто не хочет вашего обслуживания, то, скорее всего, он запускается через dbus через активацию dbus. Вы можете запустить busctl и найти, является ли ваша услуга службой, поддерживающей dbus.

Ex:

org.freedesktop.hostname1- - - (activatable) - - 

Если ваш сервис запускается с помощью активации Dbus, AFAIK, не существует простой способ узнать это [1].

Что вы можете сделать, так это то, что вы можете замаскировать службу dbus systemctl mask и дождаться сообщения об ошибке приложения, пытающегося поговорить с вашим FIREWALD.

[1] - Мне нужна эта информация, и я взломал код dbus. У меня есть патч, который работал 1-2 года назад. При необходимости попробуйте применить этот патч к dbus и повторите попытку вашей системы.

commit e1c687c96c36b7bbf2db33e967741c22fe7007c9 
Author: Umut Tezduyar Lindskog <[email protected]> 
Date: Mon Sep 22 11:13:37 2014 +0200 

    log originator of activation requests 

diff --git a/dbus/bus/activation.c b/dbus/bus/activation.c 
index 149cca8..2a9c0bd 100644 
--- a/dbus/bus/activation.c 
+++ b/dbus/bus/activation.c 
@@ -1788,6 +1788,28 @@ bus_activation_activate_service (BusActivation *activation, 
    if (connection) 
    dbus_connection_ref (connection); 

+ 
+{ 
+DBusString loginfo_buf; 
+unsigned long pid; 
+// When connection is NULL, it is that we are trying to activate systemd 
+// dbus[1106]: [system] Umut activation request by ':1.5' '/usr/bin/depd -n ' 
+// dbus[1106]: [system] Activating systemd to hand-off: service name='com.axis.Event.Switch' unit='dbus-com.axis.Event.Switch.service' 
+if (connection != NULL && dbus_connection_get_unix_process_id (connection, &pid) && _dbus_string_init (&loginfo_buf)) 
+{ 
+ if (_dbus_command_for_pid (pid, &loginfo_buf, 50, NULL)) 
+ { 
+ bus_context_log (activation->context, 
+     DBUS_SYSTEM_LOG_INFO, "Umut activation request by '%s' '%s'", 
+     bus_connection_get_name(connection), _dbus_string_get_const_data(&loginfo_buf)); 
+ 
+ _dbus_string_free (&loginfo_buf); 
+ } 
+ 
+} 
+} 
+ 
+ 
+0

Хорошая точка. Я должен замаскировать службу и посмотреть журнал, чтобы узнать, что вызывает ошибку. –

+0

Или посредственный мог остаться в тишине. Затем поиск будет продолжен. –

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