Network manager logs linux

Arch Linux

You are not logged in.

#1 2013-04-19 19:14:45

[SOLVED] Cannot find NetworkManager log file

I’m new to Arch and so far I like it a lot, but I’m still trying to get my bearings with standard stuff, like where to find NetworkManager’s log file. There isn’t any in /var/log.

The main problem is that I cannot connect to a VPN at my workplace (PPTP w/ 128bit MPEE) because nm-applet displays a very confusing and unmeaningful message «Activation of network connection failed». But for now I’d just like to know where is the #@$ log file and I’ll work my way from there.

Last edited by borisbsc (2013-04-21 13:38:18)

#2 2013-04-19 19:37:05

Re: [SOLVED] Cannot find NetworkManager log file

#3 2013-04-19 19:42:47

Re: [SOLVED] Cannot find NetworkManager log file

#4 2013-04-21 13:48:38

Re: [SOLVED] Cannot find NetworkManager log file

I even managed to solve my VPN problem. In cas anyone else has similar problems make sure you:
— install, configure and start NetworkManager properly (see Arch wiki)
— install network-manager-applet (for gnome-shell visual indicator)
— add current user to network group (gpasswd -a username network)
— instal ppp package (arch wiki makes it sound like you need to install ppp-mppe from AUR if your VPN server uses MS PPTP encryption, but that’s not true)
— make sure you explicitly enable MPPE in the advanced dialog the VPN configuration in Network Settings

Источник

A Good Bug Report.

running the command uname -r prints out your kernel version

your network device’s brand and model, including the hardware revision (usually something like «A1» or «B2»)

your network device’s hardware IDs

if it’s a USB device, include the output of lsusb -v

if it’s a PCI or CardBus device, include the output of lspci -vn

if it’s a PCMCIA device, include the output of lspcmcia -v

the output of the ‘dmesg’ command from around the time you experienced your problem

NetworkManager logs (see below)

wpa_supplicant logs (for wireless and 802.1x connections, see below)

Log File Locations

NetworkManager

Where NetworkManager log output goes varies by distribution:

Fedora: Run: sudo journalctl -u NetworkManager.service

Ubuntu: /var/log/syslog

Others: /var/log/daemon.log or /var/log/NetworkManager.log

NetworkManager uses the ‘daemon’ syslog facility, so unless your distribution has modified the location of NetworkManager’s log output specifically, all the logging will be directed to wherever your distro directs the ‘daemon’ facility’s output.

wpa_supplicant

Supplicant logging is normally directed to /var/log/wpa_supplicant.log. For wpa_supplicant 0.7 and later, this location is controlled by the /usr/share/dbus-1/system-services/fi.w1.wpa_supplicant1.service file.

For wpa_supplicant 0.6, the log location is controlled by the /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service file.

Debugging WiFi Connections

NetworkManager logs the configuration it sends to wpa_supplication in the normal syslog location. That’s very important since it tells us what parameters wpa_supplicant will use to connect to the wifi network, and it looks like this:

Next, to debug most low-level wifi problems like failure to connect or dropped connections, we need to get debug logging from the supplicant.

Debugging wpa_supplicant 0.7 and later

If your /usr/share/dbus-1/system-services/fi.w1.wpa_supplicant1.service file contains «-f /var/log/wpa_supplicant.log» on the Exec= line, then you can execute the following commands in a terminal to get verbose debug logging sent to /var/log/wpa_supplicant.log:

That’s it! Reproduce the problem and then send /var/log/wpa_supplicant.log to the NetworkManager developers. Be aware that this may include some personal and network-related information, so if you attach this log to a bug report you’ll want to make it private, and if you email the log you may not want to send it to a mailing list.

Rebooting will reset the supplicant log level, but if you want to turn it off manually, you can run the following command:

These instructions rely on wpa_supplicant being built with CONFIG_CTRL_IFACE_DBUS_NEW. If only the old D-Bus control interface has been enabled at the supplicant’s build time (like on Red Hat Enterprise Linux 6), try:

and to return to normal:

Debugging wpa_supplicant 0.6 and earlier

You’ll need to modify the D-Bus service activation file to enable debugging and the log output to a file:

• Modify /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service file and add «-dddt» to the end of the Exec= line so that the file looks like this:

Stop NetworkManager

killall -TERM wpa_supplicant

rm -f /var/log/wpa_supplicant.log

Start NetworkManager
reproduce your problem

grab /var/log/wpa_supplicant.log and send that and the NetworkManager logs to the developers

Hidden networks

Hidden networks do not broadcast their SSID. This is false security. Don’t use them if you can help it. Even Cisco says so:

In any case, people have to live with hidden SSID networks. There are a few things you can do to figure out if your driver is at fault or something else:

stop NetworkManager and killall -TERM wpa_supplicant

rmmod your device’s kernel driver, and modprobe it again

ifconfig wlan0 up (use your wifi card’s device name of course)

iwlist wlan0 scan (use your wifi card’s device name, which you can find from ‘iwconfig’)

• if your device reports an error here, your driver is broken

look for your AP’s MAC address (called a BSSID)

if you can see your AP’s BSSID but not the SSID, then NetworkManager can match up the BSSID and the SSID with the stored list in GConf.

if you do not see your AP’s BSSID, try running the ‘iwlist wlan0 scan’ command again; not every AP is found every scan

If that still doesn’t show your AP, chances are your driver is not working correctly. There is one more thing to try.

iwlist wlan0 scan essid

if that doesn’t show your AP, try it one more time

If that still doesn’t show your AP, *including the SSID*, then your driver is broken or your AP may need a reboot. At this point, only kernel driver debugging will help fix the problem. If you are using a ‘staging’, vendor, or binary driver, chances are your driver is broken and it’s unlikely to be fixed because it’s not one of the upstream official kernel drivers.

Other NetworkManager Debugging

If your problem isn’t wifi related, or you just want to get some more debugging information out of NetworkManager, you can tell NM to change it’s log level dynamically using dbus-send. NM has both log levels and log domains; the level controls how verbose NM’s log output will be. Domains control what parts of networking NM emits log messages for. For example:

will result in verbose debugging information directed to normal NetworkManager log locations. In this request, the first argument is the log level, and the second is the log domain. Leaving either of the two arguments blank (ie, an empty string) will leave that argument unchanged. See ‘man NetworkManager.conf’ for a list of available log domains.

To turn off debug logging, run the dbus-send command referenced above, except use ‘info’ as the log level instead of ‘debug’:

Debugging NetworkManager 0.8 and 0.9 3G connections

NetworkManager 0.8 and later use ModemManager for 3G device control. To get logs from modem-manager, we use the «—debug» option.

Stop NetworkManager

killall -TERM modem-manager

modem-manager —debug

start NetworkManager again

NM_PPP_DEBUG=1 /usr/sbin/NetworkManager —no-daemon

reproduce the problem

send the modem-manager and NetworkManager logs to the developers

Debugging NetworkManager 0.7.x 3G connections

(NetworkManager 0.8 uses modem-manager so this does not apply)

run NetworkManager like so:

NM_SERIAL_DEBUG=1 NM_PPP_DEBUG=1 /usr/sbin/NetworkManager —no-daemon

reproduce the issue

Copy the NetworkManager logging output and send it to the developers

• If you use a PIN to unlock the SIM, replace the PIN with XXXX before sending

Debugging NetworkManager-openvpn

with version >= 1-2: edit /usr/lib/NetworkManager/VPN/nm-openvpn-service.name and set supports-multiple-connections=false (revert the change later)

killall -TERM nm-openvpn-service

in a root terminal, run

/usr/libexec/nm-openvpn-service —debug

• start your VPN connection
• reproduce the problem
• send the nm-openvpn-service output to the developers

Debugging NetworkManager-vpnc

Debugging NetworkManager-pptp

Projects/NetworkManager/Debugging (last edited 2018-08-18 10:27:06 by AndreKlapper )

Источник

Лог файлы Linux по порядку

Невозможно представить себе пользователя и администратора сервера, или даже рабочей станции на основе Linux, который никогда не читал лог файлы. Операционная система и работающие приложения постоянно создают различные типы сообщений, которые регистрируются в различных файлах журналов. Умение определить нужный файл журнала и что искать в нем поможет существенно сэкономить время и быстрее устранить ошибку.

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

Основные лог файлы

Все файлы журналов, можно отнести к одной из следующих категорий:

Большинство же лог файлов содержится в директории /var/log .

• /var/log/syslog или /var/log/messages содержит глобальный системный журнал, в котором пишутся сообщения с момента запуска системы, от ядра Linux, различных служб, обнаруженных устройствах, сетевых интерфейсов и много другого.
• /var/log/auth.log или /var/log/secure — информация об авторизации пользователей, включая удачные и неудачные попытки входа в систему, а также задействованные механизмы аутентификации.
• /var/log/dmesg — драйвера устройств. Одноименной командой можно просмотреть вывод содержимого файла. Размер журнала ограничен, когда файл достигнет своего предела, старые сообщения будут перезаписаны более новыми. Задав ключ —level= можно отфильтровать вывод по критерию значимости.

• /var/log/alternatives.log — Вывод программы update-alternatives , в котором находятся символические ссылки на команды или библиотеки по умолчанию.
• /var/log/anaconda.log — Записи, зарегистрированные во время установки системы.
• /var/log/audit — Записи, созданные службой аудита auditd .
• /var/log/boot.log — Информация, которая пишется при загрузке операционной системы.
• /var/log/cron — Отчет службы crond об исполняемых командах и сообщения от самих команд.
• /var/log/cups — Все, что связано с печатью и принтерами.
• /var/log/faillog — Неудачные попытки входа в систему. Очень полезно при проверке угроз в системе безопасности, хакерских атаках, попыток взлома методом перебора. Прочитать содержимое можно с помощью команды faillog .
• var/log/kern.log — Журнал содержит сообщения от ядра и предупреждения, которые могут быть полезны при устранении ошибок пользовательских модулей встроенных в ядро.
• /var/log/maillog/ или /var/log/mail.log — Журнал почтового сервера, используемого на ОС.
• /var/log/pm-powersave.log — Сообщения службы экономии заряда батареи.
• /var/log/samba/ — Логи файлового сервера Samba , который используется для доступа к общим папкам Windows и предоставления доступа пользователям Windows к общим папкам Linux.
• /var/log/spooler — Для представителей старой школы, содержит сообщения USENET. Чаще всего бывает пустым и заброшенным.
• /var/log/Xorg.0.log — Логи X сервера. Чаще всего бесполезны, но если в них есть строки начинающиеся с EE, то следует обратить на них внимание.

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

• /var/log/yum.log — Для программ установленных с помощью Yum в RedHat Linux.
• /var/log/emerge.log — Для ebuild -ов установленных из Portage с помощью emerge в Gentoo Linux.
• /var/log/dpkg.log — Для программ установленных с помощью dpkg в Debian Linux и всем семействе родственных дистрибутивах.

И немного бинарных журналов учета пользовательских сессий.

• /var/log/lastlog — Последняя сессия пользователей. Прочитать можно командой last .
• /var/log/tallylog — Аудит неудачных попыток входа в систему. Вывод на экран с помощью утилиты pam_tally2 .
• /var/log/btmp — Еже один журнал записи неудачных попыток входа в систему. Просто так, на всякий случай, если вы еще не догадались где следует искать следы активности взломщиков.
• /var/log/utmp — Список входов пользователей в систему на данный момент.
• /var/log/wtmp — Еще один журнал записи входа пользователей в систему. Вывод на экран командой utmpdump .

И другие журналы

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

• /var/log/mysql/ — Лог базы данных MySQL.
• /var/log/httpd/ или /var/log/apache2/ — Лог веб сервера Apache, журнал доступа находится в access_log , а ошибки — в error_log .
• /var/log/lighthttpd/ — Лог веб сервера lighttpd.

В домашнем каталоге пользователя могут находится журналы графических приложений, DE.

/.xsession-errors — Вывод stderr графических приложений X11.

/.xfce4-session.verbose-log — Сообщения рабочего стола XFCE4.

Чем просматривать — lnav

Почти все знают об утилите less и команде tail -f . Также для этих целей сгодится редактор vim и файловый менеджер Midnight Commander. У всех есть свои недостатки: less неважно обрабатывает журналы с длинными строками, принимая их за бинарники. Midnight Commander годится только для беглого просмотра, когда нет необходимости искать по сложному шаблону и переходить помногу взад и вперед между совпадениями. Редактор vim понимает и подсвечивает синтаксис множества форматов, но если журнал часто обновляется, то появляются отвлекающие внимания сообщения об изменениях в файле. Впрочем это легко можно обойти с помощью .

Недавно я обнаружил еще одну годную и многообещающую, но слегка еще сыроватую, утилиту — lnav, в расшифровке Log File Navigator.

Установка пакета как обычно одной командой.

Навигатор журналов lnav понимает ряд форматов файлов.

• Access_log веб сервера.
• CUPS page_log
• Syslog
• glog
• dpkg.log
• strace
• Произвольные записи с временными отметками
• gzip, bzip
• Журнал VMWare ESXi/vCenter

Что в данном случае означает понимание форматов файлов? Фокус в том, что lnav больше чем утилита для просмотра текстовых файлов. Программа умеет кое что еще. Можно открывать несколько файлов сразу и переключаться между ними.

Программа умеет напрямую открывать архивный файл.

Показывает гистограмму информативных сообщений, предупреждений и ошибок, если нажать клавишу . Это с моего syslog-а.

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

Источник

Читайте также:  Windows boot manager windows failed to start repair