System logging in Linux. syslogd daemon configuration file Network logging
A list of common UNIX/LINUX daemons, in Windows OS are called services that can be used in different UNIX/LINUX modifications. UNIX/LINUX daemon names often end with the letter d as an abbreviation for English. daemon You can check whether the process/daemon is running using the top or ps aux command.
Below is a list of the names of the most common demons and their short description. The list of UNIX/LINUX daemons below is not complete/exhaustive and your UNIX/LINUX system may have one, all or several of them present or absent depending on the version/type/modification/configuration of your UNIX/LINUX system and the installed it has software on it.
| Process/Daemon | Process/daemon description |
| auditd | auditd is an audit component for Linux systems. Maintains an audit log on disk, which can be viewed using the ausearch and aureport commands. The auditctl command allows you to configure audit rules. Moreover, at startup the rules contained in the /etc/audit.rules file are loaded. Some parameters of the daemon itself can be configured in the auditd.conf file. |
| acpid | acpid (ACPI event daemon) - a daemon for responding to ACPI events, for example, responding to pressing the power button or closing the laptop lid. Power management and interaction between Linux and BIOS via ACPI (Advanced Configuration and Power Interface) and APM. ACPI "sleep" modes: S1 - everything sleeps, CPU in minimal activity mode; S3 - "Suspend to RAM" - everything goes to sleep, the CPU turns off; S4 - "Suspend to Disk" the state dump is saved to disk, the system is turned off, after turning on the system is restored from its previous place; S5 - software power off. http://acpid.sourceforge.net/ |
| atd | executes the job queue at(1) |
| autofs | Automount table format. Automount maps can be files or NIS tables referenced by the master automount table (see auto.master(5)). The tables describe the location file systems, which are automatically mounted to the base mount points (set in the auto.master file). This document describes the sun table format; for other formats (eg hesiod) this document is not applicable. Tables can be edited on the fly - these changes will be taken into account in the next operation with this table. However, this does not apply to the main table auto.master! |
| biod | Works in conjunction with remote nfsd to resolve NFS client requests. |
| certmonger | The certmonger daemon monitors and checks certificates for expiration, and can optionally renew certificates using a CA. It can manage the entire registration process from key generation to registration and renewal. |
| cgconfig | This script runs the cgconfigparser utility, which parses and configures the control group filesystem (cgroup). For analysis, the configuration file /etc/cgconfig.conf and the parameters defined in it are used. |
| cgred | Daemon managing cgroup rules :) |
| cpufreq | The script loads kernel modules to control the processor frequency. |
| cpuspeed | Changes the CPU frequency to save energy. Many modern laptops and desktop PCs support this technology. It can be used by users with Pentium-M, Centrino, AMD PowerNow, Transmetta, Intel SpeedStep, Athlon-64, Athlon-X2, Intel Core 2 processors. Laptop users are recommended to leave this daemon enabled. Disable this daemon if you want the CPU to use a fixed frequency value. |
| crond | |
| cupsd | Print server. Like access to remote printers, access to local ones, access from outside to local ones. |
| dbus | Interprocess communication system ( Wider analogue of CORBA and DCOP) |
| dbus-daemon | Daemon for working with the data bus |
| dhcpd | Daemon for dynamically determining TCP/IP configuration for clients. |
| dnsmasq | A daemon that caches DNS names and provides a DHCP server. |
| earlysyslog | Running the syslog daemon provides logging. |
| earlyxdm | Starting the X Server |
| esound | Sound daemon, with support for remote access to the sound card |
| esd | Sound server for the Enlightenment window manager and the GNOME environment. ESD mixes the audio streams of several simultaneously running programs and outputs the resulting stream to the sound card. Belongs to the esound package. |
| fam | FAM ( File Alteration Monitor) - file change monitor. The FAM daemon is used by desktop environments such as GNOME, Xfce and KDE to track and display changes made to the file system. Included in the fam package. Has a description on wiki.archlinux.org. |
| fancontrol | CPU cooler rotation speed control. Part of lm_sensors. |
| fbset | The script required for the framebuffer to work. Configures its operation, including loading kernel modules. |
| festival | A demon that enables text reading programs to work. |
| fingerd | Provides a network interface for the finger protocol, for use with the finger command. |
| firstboot | The service is specific only to Fedora. It runs only once after installation for after installation setup (setting the root password, adding users, etc.). Can be disabled after system installation. |
| ftpd | Service for transferring files via FTP protocol. |
| functions | One of the Arch Linux system initialization scripts. It describes the functions that override the values used when loading into runlevel 3. The script is used only if the user is using runlevel 5. It is part of initscripts. |
| gpm | Mouse server for console and xterm. Contained in the package of the same name. |
| gpsd | Interface for communication with GPS equipment. Most users can turn it off. |
| Haldaemon, hal | HAL stands for Hardware Abstraction Layer. A critical service for collecting information about equipment from different sources. It is recommended to leave it enabled. |
| halt | Shutdown and reboot script. |
| halt.local | A script whose commands must be executed before a shutdown or reboot begins. |
| healthd | Sets the operating temperature range of the motherboard/processor and cooler speeds. It is one of the lm_sensors components. |
| heimdal-kdc | Key distribution center. Included in the heimdal package. |
| httpd | Apache Web Server Daemon. |
| init | A Unix program that spawns all other processes. By default, the init daemon has 7 execution levels, each of which runs a predefined set of system services. Run levels: More details about runlevels: less /etc/inittab |
| inetd | Monitors network requests. If the request is valid, starts a background process to service the request. Some systems use an extended version - xinetd |
| iptables | Standard firewall in Linux. Particularly recommended for direct connection to the Internet (via cable, DSL, T1). Not recommended if you additionally use a hardware firewall (Netgear, Linksys, D-Link, etc.). |
| ip6tables | The iptables service works using the IPv6 protocol. If you have disabled IPv6 support, then this service should be disabled. Otherwise, it is recommended to leave it enabled. |
| irda | IrDA is needed to support devices that operate via infrared ( laptops, PDAs, mobile phones, calculators (translator's note: calculators? o_O), etc. Most users can turn it off. |
| irexecd | Demon for infrared. Comes with lirc-utils. |
| irqbalance, irq_balancer | In multiprocessor systems, it is used to distribute interrupts between processors. Users who do not have multiprocessor computers/laptops can disable this daemon/service. Enabling this service on a single processor computer will not have any effect. On new computers with more than one processor (Intel Core 2 Duo, AMD X2), this service must be enabled. |
| ivman | The daemon is responsible for auto-mounting devices in the system (CDs, USB drives, etc.) |
| jackd, jack-audio-connection-kit | Audio server |
| jexec | Provides support for launching and running applications in java - JAR. Will be available if you install Java from Sun. This is optional and can be disabled. |
| joystick | A script that loads kernel modules for the joystick to work. |
| kadmind | Daemon for determining the accounts that have access to the Kerberos database and their access level. It is one of the components of the heimdal package. |
| kdump | kdump - display kernel trace data. The command displays the kernel trace files produced with ktrace(1) in human readable format. By default, the file ktrace.out in the current directory is displayed. |
| kbd | Setting up the keyboard in the virtual terminal. |
| kdm | KDM ( KDE Display Manager) is one of the programs in the kdebase package ( included with KDE), which provides the ability to log in via a graphical interface. |
| kpasswd | Daemon for changing passwords in Kerberos. It is one of the components of the heimdal package. |
| ksysguardd | KDE daemon for system monitoring. |
| libvirtd | Daemon for managing QEMU guest machines and networks. |
| libvirt-guests | A script that sends guest operating systems to sleep mode when shutting down and wakes them up when loading. |
| lircd | The LIRC daemon decrypts signals coming from the infrared port. Comes with lirc-utils. |
| lircmd | LIRC daemon translating mouse signals. Comes with lirc-utils. |
| lvm2-monitor | Daemon for monitoring LVM (Logical Volume Management). Recommended if you are using LVM, otherwise leave it disabled. |
| lpd | “Line Printer Daemon” - the protocol is used to manage the print spool. |
| mdadm | The daemon monitors MD devices (software RAID in Linux). |
| mdmonitor and mdmpd | These two daemons are used in storage systems with RAID arrays (redundant array of inexpensive/independent disks). Mdmonitor starts, stops, and restarts mdadm (multipath device monitoring and management), a RAID monitoring and management software service. You only need to run this service if your system has RAID devices. |
| messagebus | Interprocess communication service for Linux. Critical Component because it is connected to D-BUS. It is highly recommended to leave it enabled. |
| microcode_ctl, microcode.ctl | A service that allows you to update the firmware of an Intel processor (Pentium Pro, PII, Celeron, PIII, Xeon, Pentium 4, and so on). Updates are recorded every time you download. Should only be enabled if you have an Intel processor. |
| mcelog, mcelogd | To monitor hardware problems in 64-bit Linux builds, it is convenient to use the mcelog package, which analyzes the MCE (Machine Check Exception) status in AMD and Intel CPUs, which can indicate problems with memory and CPU cache, data exchange errors between the CPU and the motherboard chipset . |
| mpd | Music Player Daemon - music player having a client-server architecture that plays music from a specified directory. |
| multipathd | Used to monitor Multi-Path devices, that is, drives that can be accessed by more than one controller or method. |
| mysqld, mysql | MySQL Database Daemon |
| nfsd | NFS operator request process for client systems. Historically, each nfsd daemon supports one request at a time, so several copies are launched. |
| netconsole | Allows you to export the console to another machine over the network. May be disabled by default. |
| netfs | During boot, it automatically mounts file systems available over the network ( NFS, Samba and others). Most desktop and/or laptop users can turn it off. |
| network | Daemon responsible for creating and configuring local network interfaces (LAN) |
| network-remotefs | Same as the previous one, but additionally raises wireless interfaces |
| nfs, nfslock | The services provide a standard network file system for Unix/Linux and BSD operating systems. If you need to open access via NFS, leave it enabled, otherwise you can turn it off. |
| nginx | nginx is a web server and mail proxy server running on Unix-like operating systems. |
| nmbd | Samba is used. See Samba below. |
| nscd | Server daemon that caches names and passwords used by services such as NIS, NIS+, LDAP, hesiod. Can be turned off. |
| nslcd | local LDAP name service daemon. |
| ntpd | NTP daemon that manages time synchronization over the network. xntpd is equipped with version 3 of the NTP standard. |
| ntpdate | |
| oddjobd | The oddjobd daemon provides the com.redhat.oddjob service on the system-wide message bus. Each facility which oddjobd provides is provided as a separate D-Bus method. |
| openntpd | Server and client for time synchronization. |
| openvpn | Provides a secure method for creating a VPN. For additional information see OpenVPN. May be disabled if not used by NetworkManager. |
| pcmcia | Provides support for pcmcia standard expansion cards. Typically used only in laptops. |
| pcscd | Provides support for card readers and smart cards. If you do not have a card reader or smart cards, you can turn off this service. Often available on laptops. |
| portreserve | Prevents access to real ports for various RPC services and gives priority to reserved applications. More detailed information can be found in the portreserve man page. It is recommended to leave it enabled. |
| powerfail | This script is run when messages from UPS are detected |
| postfix | Postfix mail management program |
| pppd | Point-to-Point Protocol Daemon |
| ppp | Script for working with the pppd daemon. |
| psacct | Manages Linux kernel processes. Engaged in monitoring. |
| purge-kernels | Script for automatic deletion old kernels ( configured in /etc/zypp.conf) |
| quota_nld | quota netlink message daemon |
| raw | The script loads raw device modules. |
| rdisc | The network gateway discovery daemon, rdisc, acts as an ICMP Gateway Discovery Protocol client. rdisc is called at boot to obtain the network's routing tables with default gateways. |
| rdate | the service is needed to synchronize the computer with the time server when booting operating system. Can be disabled. |
| restorecond | Used to restore context and monitor SELinux policy related to files. The service is not required, but recommended when using SELinux. |
| rngd | rngd - Check and feed random data from hardware device to kernel random device. Literally it can be translated as a demon that checks and receives random data from hardware devices for the kernel of random devices - how clever it is :), random number generator daemon, in Russian the demon of generating random numbers. |
| rpcbind | Daemon for managing RPCs that are used by other services (like NFS or NIS). Works similar to portmap. Can be disabled if there are no other services dependent on it. |
| rpcgssd, rpcidmapd, rpcsvcgssd | NFS v4 (Network File System) is used. Disable if you don't need NFS v4. http://ru.wikipedia.org/wiki/Network_File_System |
| rsyslog | rsyslog serves for convenient collection and processing of system logs and positions itself as an extended syslogd module for Unix systems and Linux, which focuses on security and reliability, and also has advanced multi-threading. Rsyslog offers a wide range of features, which can be found by clicking on the link - RSyslog features. http://www.rsyslog.com/module-Static_Docs-view-f-features.html.phtml |
| rsync | rsync ( Remote Synchronization) is a program for UNIX-like operating systems that synchronizes directories and files in several places while minimizing traffic, using data encoding if necessary. rsync was created as a replacement for rcp and scp. Read more... |
| saslauthd | SASL authentication server daemon. SASL ( Simple Authentication and Security Layer) provides the ability to authenticate in protocols based on remote connections. |
| samba, smbd | Samba server daemon. |
| sendmail | Provides support for local IMAP or POP3 service, leave it enabled. The service may be useful for notifying about the activity of various daemons/services, which can be provided via cron or sending mail from PHP scripts. |
| sensord | The daemon from lm_sensors collects information from various sensors. |
| sensors | A script that, if necessary, loads the necessary kernel modules to work with lm_sensors. |
| shorewall | Script for managing the shorewall firewall. |
| slim | Login manager for X's. |
| smartd | The SMART daemon monitors disks. Used to predict failures and monitor drives or hard drive problems. Typically, users do not need this daemon, but it is still recommended (especially for servers) to leave it enabled. |
| smb | The SAMBA daemon is required to open the common network access to files on Linux for Windows users. Must be enabled if you have Windows machines on your network that need to be given access to files. |
| smolt | A daemon that sends information monthly to collect statistics to help developers. Statistics are available to everyone. Users who wish to help developers must enable this service. |
| snmpd, snmptrapd | Provide SNMP support ( Simple Network Management Protocol), which can be used to manage and configure devices such as network hubs, servers, printers, etc. and so on. Can be disabled, but may be required to run HP Print Services ( hplip). |
| squid | Squid proxy daemon. |
| sshd | Listens for secure shell requests from clients. SSH allows other users to log in over the network from another computer and run applications on your computer, typically used for remote administration. This could be a potential security risk. On workstations that do not require remote access, it is advisable to turn it off. |
| sssd | SSSD ( System Security Services Daemon) allows access to remote authentication mechanisms. This blurs the line between network and local authentication and allows the use of different mechanisms. Information about users is transmitted by a database called a domain and can be a source of data for remote authentication. Multiple mechanisms are allowed, allowing multiple servers to implement different namespaces. The received information is provided to external applications using standard NSS and PAM interfaces. SSSD runs as a set of services that are independent of the application calling them, so applications do not need to initiate their own connections to remote domains, nor do they need to know which daemon/service is in use. Local caching of group information and identity data allows regardless of the data source ( LDAP, NIS, IPA, DB, Samba, etc.) continue to work offline, which overall improves productivity. SSSD may allow multiple providers of the same type ( for example LDAP). |
| svnserve | svn server daemon. |
| sysstat | The Sysstat package contains utilities for monitoring system performance and resources used. |
| swapper | Copies the local process into swap space to fix the physical memory page for the kernel. Also called sched. |
| syslogd | System process for recording various system messages. |
| syncd | Periodically synchronizes with system memory established system files. |
| syslog-ng | The daemon keeps system logs. |
| udev-post | System device manager used by udev. By default, udev supports a large number of rules, behaviors, and permissions for devices. Using this service you can safely manage rules. It is recommended to leave it enabled. |
| vhand | Frees memory pages for use by other processes. Also known as "page stealing daemon". |
| vsftpd | vsftpd ( Very Secure FTP Daemon - Very Secure FTP Daemon) - FTP server supporting IPv6 and SSL. vsftpd is used by default on many UNIX-like operating systems, also serves the official repositories ftp.openbsd.org, ftp.freebsd.org, ftp.debian.org, ftp.redhat.com and is used on the official Linux kernel FTP server. |
| webmin | System management service via browser ( web interface). |
| winbind | A service that helps you distinguish on the network computer names under Windows control. Can be used to control accounts Windows with Linux accounts. Typically, most users do not need this daemon and can leave it disabled. |
| wpa_supplicant | The service is needed to work with wireless cards, which are used to connect to access points ( VPN or Radius servers) require WPA encryption. Most users can leave it disabled. |
| xfsd | Serves X11 fonts for remote clients. |
| yam | service for updating RPM packages installed on the system. Used primarily in Fedora Core. |
| ypbind | The service is used for NIS authentication over the network. If NIS authentication is not used, you can disable it. |
| zvbid | A service that provides access from V4L or V4L2 devices to several applications. For example, a card for capturing Hauppage can use this service, in other cases it can be turned off. |
If the above list of UNIX/Linux daemons/services does not work on your system, then to get help about such a service use man name_daemon, and if there is no information about the running service there, then write in comments and together we will collect information on such a service and add to the list of UNIX/Linux daemons/services given here.
If there is no description of the service in the man name_daemon help, then the daemon/service may be a virus, in this case, search for the executable file whereis name_daemon and send it for analysis to a virus laboratory - this can be done without installing an antivirus through the web interface, for example http://vms.drweb.com/online/, http://www. esetnod32.ru/.support/scanner/ or https://www.virustotal.com/.
Autoloading UNIX/LINUX daemons/services
Below are detailed instructions for managing startup of daemons/services in the most common modifications/versions of UNIX-like OS such as CentOS Linux, Debian Linux and BSD type OS. In other modifications/versions of UNIX-like OSes, the management of autoloading of daemons/services has a similar procedure, although it may have some minor or even radical differences!
Autoloading Daemons/Services on CentOS Linux
CentOS has defined load levels according to the System V principle and are painted in the /etc/inittab file, read less /etc/inittab .
The directories for each load level are named and located in the /etc/rc.d directory.
In each of the directories that corresponds to a particular load level there are scripts, or rather links to them, with instructions for starting the daemon/program/service, and the scripts themselves with instructions for starting the daemon/program/service are located in the /etc directory /rc.d/init.d
An example of scripts that control the launch of a daemon/program/service can be viewed by running less /etc/rc.d/init.d/mysqld or less /etc/rc.d/init.d/sshd . Typically, scripts that control the launch of a daemon/program/service appear in /etc/rc.d/init.d/ and are linked to runlevel directories after software installation, and their status is off/on for each run level controlled by chkconfig utility.
You can see which daemons will be running at different run levels with the chkconfig --list command. You can enable the daemon to run automatically in any of the run levels using the command chkconfig --level 345 mysqld on , and turn off chkconfig --level 345 mysqld off respectively, chkconfig –del service_ name to delete a service, chkconfig service_name on|off to enable or disable a service at all levels.
As for adding scripts to startup, then For automatic download scripts are served by /etc/rc.local, in /etc/rc.local it is enough to add the full path to the script, for example: /root/scripts/script.sh or /bin/sh /root/scripts/script.sh . If after installing the software there is no startup control script in /etc/rc.d/init.d/ the desired program, then it’s easier to add its initialization/launch line to /etc/rc.local.
There is a utility called ntsysv to manage runlevels, man ntsysv.
Autoloading Daemons/Services on Debian Linux
The directories for each boot level in Debian Linux are also named rc0.d, rc1.d, rc2.d, rc3.d, rc4.d, rc5.d, rc6.d But, located no longer in the /etc/rc.d directory, but in the root of the /etc directory
There were scripts with instructions for starting the daemon/program/service, or rather symbolic links to them are located in the /etc/rc?.d directories where is the sign? corresponds to the load level, and The scripts themselves with instructions for starting the daemon/program/service are located in the /etc/init.d directory. An example of such a skipt, based on which you can write your own, can be found in the file less /etc/init.d/skeleton.
Below we will give an explanation of the service information used in the script template /etc/init.d/skeleton:
- Provides: Describes the objects provided by this script (arg1, agr2, ...) in such a way that when the script is run with the argument start, these objects are considered to exist, and therefore other scripts in init that require the existence of these objects will be able to start at more late stage. Typically, you can use the name of the script as the object, but you can also use the name of the service that it replaces. Virtual objects are not indicated here. They are defined outside of the init.d scripts
- Required-Start: Specifies objects that must exist to run the script. If necessary, you can use virtual objects as described below. If objects are not specified, then the script can be launched immediately after start, without the need to connect local file systems, start the system log, etc.
- Required-Stop: Specifies the objects used by the service, provided by the script. The object provided by this script must complete before the objects listed here complete to avoid conflicts. Typically, the same objects are indicated here as in Required-Start
- Should-Start: Specifies the objects that, if they exist, should be started before the service provided by this script. This allows for weak dependencies that do not cause the service to fail if objects are not available. You can use virtual objects as needed, as described below.
- Should-Stop: Specifies objects that, if they exist, should be stopped after of this service. Typically, the same objects are specified here as in Should-Start
- Default-Start: Sets the run levels at which the script should be started (stopped) by default. For example, if the service should be started at only levels 3, 4 and 5, specify "Default-Start: 3 4 5" and "Default-Stop: 0 1 2 6".
- Short-Description: Specifies a short description of the script action. Limited to one line.
- Description: Specifies a more detailed description of the script action. May be on multiple lines, in which case each line of description must begin with a # character followed by a tab character or at least 2 space characters. The description ends before a line that does not match this condition.
- X-Start-Before, X-Stop-After: Specifies inverse dependencies that have the same meaning as if they were specified in should-start and should-stop in the packages specified here.
The keywords provides, required-, and should- are important for tracking dependencies. The rest are not used. Runlevels are used by the program by default to organize scripts ( for example, insserv) in order to keep track of which directory rc?.d update when a service is first added and should reflect the purpose of the service. Here are some "virtual" objects:
- $local_fs- All local file systems are connected. All scripts that write to /var/ should depend on this unless they already depend on $remote_fs
- $network- low-level network, i.e. network cards, may imply PCMCIA running
- $named- Daemons that can provide domain name resolution are assumed to be running. For example, DNS, NIS+ or LDAP
- $portmap- Daemons providing the SunRPC/ONCRPC portmapping service as specified in 1833 (if any)
- $remote_fs- All file systems are connected. Scripts that must be run during a system shutdown before a kill signal is sent to all processes must depend on $remote_fs.
- $syslog- the system log is functioning
- $time- the correct system time is set, for example, ntp or rdate, or RTC
- $all- Runs the script as last as possible
Daemon autoloading in Debian Linux is controlled using the update-rc.d utility, detailed in man update-rc.d . The update-rc.d utility does not create or delete anything other than symlinks in /etc/rc?.d to the so-called init scripts that control the start and stop of the daemon/program/service, which are located in the /etc/init.d directory.
If the script for autostarting the daemon/service is created manually using the template /etc/init.d/skeleton, then you must first place it in the /etc/init.d directory, then create a symbolic link to this script in the /etc/rc?.d directory, where? - runlevel number ( system load level). The symbolic link should look like this: S№№script_name, where No. is the launch order number, if you want to leave a symbolic link but not run the script temporarily, then the symbolic link should be modified to this state KNo. script_name.
Before any execution level can be processed, all scripts that begin with the letter " are executed first. K" (these scripts stop services), and then all scripts that begin with the letter " are executed S" (these scripts start services). The two-digit number after the letter "S" or "K" indicates the order in which the scripts will be executed. Scripts with a lower number are executed first, for example: S01script_name will start first, and S09script_name will be launched ninth.
To create a symbolic link, use the program ln -s file1 file2 , Where key -s talks about creating a symbolic link, file1 points to an existing file, and file2 the name of the new link, but instead of creating symbolic links manually, you can use the update-rc.d utility, which is designed specifically for creating symbolic links in /etc/rc?.d to scripts from /etc/init.d.
The update-rc.d syntax is like this: adding with default parameters update-rc.d
Frankly, update-rc.d is a relatively opaque utility, The chkconfig utility is more convenient, which is not available by default on Debian Linux. To install it, we need to add additional repositories, it is advisable to use only official Debian Linux package repositories, to the end of the list vi /etc/apt/sources.list, example sources.list in Debian GNU/Linux 6.0.5 _Squeeze_ - Official i386:
# # deb cdrom:/ squeeze main deb cdrom:/ squeeze main deb http://security.debian.org/ squeeze/updates main deb-src http://security.debian.org/ squeeze/updates main # squeeze-updates , previously known as "volatile" # A network mirror was not selected during install. The following entries # are provided as examples, but you should amend them as appropriate # for your mirror of choice. # # deb http://ftp.debian.org/debian/ squeeze-updates main # deb-src http://ftp.debian.org/debian/ squeeze-updates main deb http://backports.debian.org/ debian-backports squeeze-backports main deb http://ftp.debian.org/debian/ squeeze main #deb http://repo.yandex.ru/debian squeeze main contrib #deb http://mirror.yandex.ru/ debian squeeze main contrib #deb http://mirror.yandex.ru/debian-multimedia/ squeeze main contrib
Then update the list of packages with apt-get update and install chkconfig apt-get install chkconfig , and as an alternative, you can additionally install sysv-rc-conf apt-get install sysv-rc-conf . How to use the chkconfig utility was mentioned above, additionally see man sysv-rc-conf and man chkconfig.
When adding Debian Linux repositories, be aware of the software policies that apply to each of the areas such as main, contrib and non-free:
- main: - The packages in this area are part of the complete Debian Linux distribution and none of the packages in the main area require software from outside this area to function fully. Anyone can freely use, share, modify and distribute packages from the main area.
- contrib: - Packages from this area can be freely distributed, but some of their dependencies may not be free.
- non-free: - contains packages that cannot be distributed for free according to the DSFG, and packages from the area may contain errors that are not taken into account when developing and updating Debian Linux.
To autorun other scripts and programs in Debian Linux, you can use the good old /etc/rc.local.
System administrators, and regular Linux users, often need to look at log files to troubleshoot problems. In fact, this is the first thing any system administrator should do when any error occurs in the system.
The Linux operating system itself and the running applications generate various types of messages that are logged in various log files. Linux uses special software, files and directories to store log files. Knowing which files contain the logs of which programs will help you save time and solve the problem faster.
In this article we will look at the main parts of the Linux logging system, log files, as well as utilities with which you can view Linux logs.
Most files Linux logs are located in the /var/log/ folder. You can list the log files for your system using the ls command:
Rw-r--r-- 1 root root 52198 May 10 11:03 alternatives.log
drwxr-x--- 2 root root 4096 Nov 14 15:07 apache2
drwxr-xr-x 2 root root 4096 Apr 25 12:31 apparmor
drwx------ 2 root root 4096 May 5 10:15 audit
-rw-r--r-- 1 root root 33100 May 10 10:33 boot.log
Below we will look at 20 different Linux log files located in the /var/log/ directory. Some of these logs are only found on certain distributions, for example dpkg.log is only found on Debian based systems.
/var/log/messages- contains global Linux system logs, including those that are recorded at system startup. Several types of messages are recorded in this log: mail, cron, various services, kernel, authentication and others.
/var/log/dmesg- contains messages received from the kernel. Logs many messages during the boot phase, they display information about hardware devices that are initialized during the boot process. You can say this is another log of the Linux system. The number of messages in the log is limited, and when the file is full, with each new message the old ones will be overwritten. You can also view messages from this log using the dmseg command.
/var/log/auth.log- contains information about user authorization in the system, including user logins and authentication mechanisms that were used.
/var/log/boot.log- Contains information that is logged when the system boots.
/var/log/daemon.log- Includes messages from various background daemons
/var/log/kern.log- Also contains messages from the kernel, useful in troubleshooting errors in custom modules built into the kernel.
/var/log/lastlog- Displays information about the last session of all users. This is a non-text file and you must use the lastlog command to view it.
/var/log/maillog /var/log/mail.log- logs of the email server running on the system.
/var/log/user.log- Information from all logs at the user level.
/var/log/Xorg.x.log- X server message log.
/var/log/alternatives.log- Information about the operation of the update-alternatives program. These are symbolic links to default commands or libraries.
/var/log/btmp- log Linux file contains information about failed login attempts. To view the file, it is convenient to use the command last -f /var/log/btmp
/var/log/cups- All messages related to printing and printers.
/var/log/anaconda.log- all messages recorded during installation are saved in this file
/var/log/yum.log- Logs all information about package installations using Yum.
/var/log/cron- Whenever the Cron daemon starts executing a program, it writes a report and messages from the program itself in this file.
/var/log/secure- contains information related to authentication and authorization. For example, SSHd logs everything here, including failed login attempts.
/var/log/wtmp or /var/log/utmp - Linux system logs , contain a log of user logins. Using the wtmp command you can find out who is logged in and when.
/var/log/faillog- log linux systems, contains failed login attempts. Use the faillog command to display the contents of this file.
/var/log/mysqld.log- Linux log files from the MySQL database server.
/var/log/httpd/ or /var/log/apache2- log files of linux11 Apache web server. Access logs are in the access_log file, and error logs are in the error_log
/var/log/lighttpd/ - linux logs lighttpd web server
/var/log/conman/- ConMan client log files,
/var/log/mail/- this directory contains additional mail server logs
/var/log/prelink/- Prelink program links libraries and executable files to speed up the download process. /var/log/prelink/prelink.log contains information about .so files that were modified by the program.
/var/log/audit/- Contains information generated by the auditd daemon.
/var/log/setroubleshoot/ - SE Linux uses the setroubleshootd daemon (SE Trouble Shoot Daemon) to report security problems. This log contains messages from this program.
/var/log/samba/- contains information and logs from the Samba file server that is used to connect to shared folders Windows.
/var/log/sa/- Contains .cap files collected by the Sysstat package.
/var/log/sssd/- Used by the system security daemon that manages remote access to directories and authentication mechanisms.
Viewing logs in Linux
To view logs on Linux it is convenient to use several command line utilities Linux strings. It could be anyone text editor, or special utility. Most likely, you will need superuser rights to view logs in Linux. Here are the commands that are most often used for these purposes:
- zgrep
- zmore
I will not go into detail on each of these commands, since most of them have already been discussed in detail on our website. But I will give a few examples. Viewing Linux logs is very simple:
We look at the log /var/log/messages, with the ability to scroll:
less /var/log/messages
View Linux logs in real time:
tail -f /var/log/messages
Open the dmesg log file:
cat /var/log/dmesg
First lines of dmesg:
head /var/log/dmesg
We only output errors from /var/log/messages:
grep -i error /var/log/messages
In addition, you can view logs on Linux using graphical utilities. System program Log Viewer can be used to convenient viewing and monitoring system logs on a laptop or personal computer with Linux.
You can install the program on any system with an X server installed. Also, any graphical test editor can be used to view logs.
conclusions
In the /var/log directory you can find all the necessary information about the operation of Linux. From today's article you have learned enough to know where to look and what to look for. Now viewing logs in Linux will not cause you problems. If you have any questions, ask in the comments!
Each of the novice Linux users sooner or later encounters some problems in setting up and organizing the functioning of their system. And each of the newcomers has almost certainly heard advice from more experienced users: “Look at the logs.” The advice is good, but a beginner still needs to know: what logs are and where to look for them! So in this article I will try to tell you what to watch and where.In programming slang, “logs” are work protocols that are maintained both by the operating system itself and independently by many programs. The word “journal” is often used as a synonym for the word “protocol” in this sense. There are two main situations in which the need to analyze a protocol arises: when something in the system does not work as we expected (problem resolution), and when there is a suspicion that the system has been hacked by some attacker and we need to find out what exactly happened , how it was done, and what needs to be done to eliminate the consequences of the invasion.
One of the most famous cases of using log files to detect an attacker's intrusion is the story of the capture of the famous hacker Kevin Mitnick by computer security specialist Tsuomo Shimomura. Here is one paragraph from an article describing how this happened.
"On Christmas Day, when Shimomura went skiing in Nevada for the holidays, someone (we already know who) broke into his super-secure home computer in Solana Beach, California, and began copying his files - hundreds of classified files. One graduate student at the Supercomputing Center in San Diego, where Shimomura worked, noticed changes in the system "log" files and quickly realized what was happening. All this was possible thanks to the fact that Shimomura installed a program on his computer that automatically copies “journal” entries to a backup computer in San Diego. The student called Shimomura, who rushed home to take inventory of the stolen items."
I will not tell the whole story here; it is important for us to note only that the analysis of the system's operation protocols served as the basis for the success of the investigation into misconduct. You can find a more detailed description of how such investigations are carried out in the article. But in order to be able to take advantage of the results of logging, you need to understand how protocols are created, where they are stored and what can be extracted from them. This article is devoted to the consideration of all these issues.
How messages for the protocol are generated
We need to start with the fact that when creating programs in the C language, programmers have the opportunity, if necessary, to insert calls to special functions openlog, setlogmask, syslog And closelog, included in the standard library of the C language. These functions are used to send messages about certain events during program execution to a special system daemon syslogd, conducting the system protocol. Function openlog establishes a connection with a demon syslogd, function syslog generates a specific message to be recorded in the protocol, and the function closelog closes an open connection.
Messages generated by the function syslog, consist of several fields separated by spaces. Each message begins with a field PRI, which in encoded form contains information about the category of the message (facility) and the severity level (severity level) or priority (priority) of the message.
Category (facility) is information about which class this message belongs to. The category is coded with a number from 0 to 23. The following categories exist (they are defined in the file /usr/include/sys/syslog.h):
Table 1.
| Numeric value | Symbol | Decoding |
| 0 | kern | Kernel messages |
| 1 | user | Designed for various messages from user programs. (messages from user programs) |
| 2 | Messages from postal system. | |
| 3 | daemon | Messages from those system daemons that, unlike FTP or LPR, do not have categories dedicated specifically to them. |
| 4 | auth | Everything related to user authorization, like login and su (security/access rights) |
| 5 | syslog | The logging system can log messages from itself. |
| 6 | lpr | Messages from the printing system. |
| 7 | news | Messages from the news server. (Netnews, USENET) |
| 8 | uucp | UNIX-to-UNIX Copy Protocol messages. It's part of UNIX history and you'll probably never need it (although some mail is still delivered via UUCP). |
| 9 | cron | Messages from the system scheduler. |
| 10 | authpriv | Same as auth, but messages in this category are written to a file that only some users can read (perhaps this category is selected because messages belonging to it may contain clear user passwords that should not be seen by strangers, and therefore log files must have appropriate access rights). |
| 11 | ftp | Using this category, you can configure your FTP server so that it records its activities. |
| from 12 to 15 | - | Reserved for system use. |
| from 16 to 23 | local0 - local7 | Reserved categories for use by the system administrator. The local7 category is typically used for messages generated during the system boot phase. |
Category auth has an outdated synonym name security, which is not recommended. In addition, there is a special category mark(which has no digital equivalent), which is assigned to individual messages generated by the demon itself syslogd. This category is used to place special marks in the protocol at a specified time interval (every 20 minutes by default), which allows, for example, to find out with 20-minute accuracy when your computer froze.
Note that the category has generally nothing to do with the name of the program that sends messages to the daemon syslogd. As they say, every coincidence is pure chance. Moreover, some programs may generate messages of different categories. For example, a demon telnetd in case of unsuccessful logging attempts, generates category messages authpriv, and in other cases categorizes their messages daemon.
The second parameter on the basis of which the field value is formed PRI, is the level or priority of the message (priority), that is, information about the degree of importance of the message. By default, 8 levels of importance are specified (they are also defined in the file /usr/include/sys/syslog.h), which are coded by numbers from 0 to 7:
Table 2.
| Numeric value | Symbol | Decoding |
| 0 | emerg(old name PANIC) | Emergency. The system is inoperative. |
| 1 | alert | Anxiety! Immediate intervention is required. |
| 2 | crit | Critical error(critical condition). |
| 3 | err(old name ERROR) | Error message. |
| 4 | warning(old name WARN) | Warning. |
| 5 | notice | Information about some normal but important event. |
| 6 | info | Announcement. |
| 7 | debug | Messages generated during debugging. |
Field PRI The message is formed as follows: the numeric value of the category is multiplied by 8 and added to the numeric value of the priority, the resulting number is enclosed in angle brackets and written in the field.
Following the field PRI The message includes the following fields:
- TIMESTAMP- message generation time,
- HOSTNAME- host name or IP address in decimal notation,
- MSG- arbitrary message text - some text (information) string in US-ASCII code (0x20 - 0x7e).
Time (local!) is written in the format: Feb 13 21:12:06. If the day number is a single digit, then an additional space (not 0!) is placed in front of it. Please note that there is no year and zone in the date, which must be taken into account when organizing long-term storage of log files. In order for the time in the message to be correct, it must be synchronized (for example, using the NTP protocol).
The hostname is included in the message to avoid confusion between messages from different hosts, since, as will be shown below, logging can be done on one of the dedicated computers on the network. The host name is the simple network name of the computer, without specifying the domain. If a computer has several interfaces with different IP addresses, then any of them can be used as the host name or address.
Message text ( MSG) usually contains a label ( TAG), indicating the program or process that issued the message, and the body of the message ( CONTENT). The label may contain Latin letters and numbers. Typically the label is simply the program name, sometimes supplemented by a process identifier enclosed in square brackets. The body of the message is separated from the label by special characters - in Linux these are usually a colon and a space.
Processing messages by the syslogd daemon
All messages generated by individual programs using the function syslog, sent via socket /dev/log system daemon syslogd, which is responsible for processing these messages. It must be said that, in fact, two logging daemons are launched in the system - syslogd And klogd. Both daemons are included in the package sysklogd, the latest version of which you can find on the website.
Daemon klogd is responsible for logging events occurring in the system kernel. The need for a separate daemon klogd due to the fact that the kernel cannot use the standard function syslog. The fact is that standard libraries(including the library in which the function is located syslog) are intended for use by regular applications only. Since the kernel also needs similar functions, it includes its own libraries that are not available to applications. Therefore, the kernel uses its own message generation mechanism. Daemon klogd is designed to organize the processing of these messages. In principle, he can carry out such processing completely independently and independently of syslogd, for example, by logging these messages to a file, but in most cases the default setting is used klogd, in which all messages from the kernel are forwarded to the same daemon syslogd.
To make sure the demons syslogd And klogd running on your system, run the command ps -ax | grep log. This command gave me the following result:
$ ps -ax | grep log 569? S 0:00 syslogd -m 0 574 ? S 0:00 klogd -x 1013 ? S 0:00 login -- kos 1191 ? S 0:00 kalarmd --login The first two lines indicate that logging daemons are running in the system.Processing messages by the daemon syslogd is that it constantly monitors the appearance of messages and compares each incoming entry with the rules that are in the file /etc/syslog.conf. Each rule is written as a file line /etc/syslog.conf, consisting of two fields. The left field ("selector") specifies one or more templates by which messages are selected. Patterns are separated by semicolons (see example file below /etc/syslog.conf). The right field (“action”) determines the order in which selected messages are processed. Fields are separated by one or more spaces or tab characters.
Each pattern in the "selector" field is of the form "category.level" (that is, "facility.priority"). The values of the "category" field can be:
- one of the conventional names of categories listed in Table 1,
- several such names (in this case they are separated by commas)
- or the * symbol (meaning "all categories").
The values of the "level" field can be:
- one of the level names listed in Table 2,
- symbol * (record all messages of this category, regardless of level),
- or word none(do not record messages in this category).
Specifying a specific value in the "level" field is interpreted as "all values this level and higher". If you need to record messages of only one level, then you need to put an equal sign ("=") in front of the specified value. If you want to record messages of all levels except the specified one, then put before the name of the level Exclamation point("!"). Placing these two signs at the same time is interpreted as “do not record messages of the specified level or higher.”
There is no difference between uppercase and lowercase letters in the "selector" field. You can also use numbers (see /usr/include/syslog.h). In addition to the categories listed in Table 1, you can indicate mark(regular timestamps) and security(obsolete synonym for auth). In addition to the priority values listed in Table 2, you can use warn(synonym for warning), error(synonym for err), panic(synonym for emerg).
When a match is found between the category and level of a received message and one of the patterns in the "selector" field of some string, syslogd processes the record in accordance with the action specified in the “action” field of this line.
The "action" field can contain
- the name of a regular file (log file), and the full path to the file must be specified, starting from the root "/", and if the specified file does not exist, syslogd creates it,
- name of the named pipe - FIFO; in this case, a vertical bar ("|") is placed before the name, and the channel itself must be created before starting syslogd team mkfifo,
- pointing to a terminal or console (as in device: /dev/tty1),
- an indication of the remote host (preceded by the @ symbol),
- or a list of users (separated by commas) to whose terminals a message will be sent according to this rule. Instead of a list of users, you can put an asterisk (*), which will mean that messages are sent to all users working in this moment in system.
Most often, the “action” field still contains the name of the log file. Moreover, you can put a minus sign ("-") in front of the file name, which will mean that the system can store the file in the cache buffer, rather than flush it after writing each message to disk. This, of course, speeds up the work, especially if many large messages are written to the protocol, but it can lead to the loss of some messages in the event of an unexpected system crash, that is, exactly when such messages are especially needed. You can also specify a printer - /dev/lp0 - as a device in the "action" field. This option of “action” is advisable to use in cases where particularly important systems are involved. Protocols that are printed out cannot be erased or altered by hackers, so this is a good use for an old dot matrix printer.
In addition to the lines with the rules in the file /etc/syslog.conf may contain empty lines and comment lines starting with the # symbol. More about file structure /etc/syslog.conf You can read the syslog.conf man page for quite a few examples of rule entries in this file. Note that when specifying “category.level” pairs in the file syslog.conf can not use numeric values, given in tables 1 and 2, only their conventional names are allowed.
If a message matches the patterns of two or more strings, it will be processed according to each of those rules (that is, message processing does not stop on the first success). This means that an arbitrary number of actions can be performed for one message. Therefore, you can write the message to a log file and send it to the user(s) or to a remote host.
In addition, if the "selector" field lists (separated by semicolons) several "category.level" pairs, then subsequent pairs can override the previous ones. You can see an example of such cancellation in the file listing below /etc/syslog.conf: All messages whose level is equal to or higher than info are written to the /var/log/messages file, but messages from the mail, authpriv and cron categories are skipped (not written).
| Listing 1. File /etc/syslog.conf from a system built on the Red Hat Linux 7.1 distribution (I only translated the comments contained in this file into Russian and highlighted the rules in bold). |
| # Print all messages from the kernel to the console. #kern.* /dev/console# Log all messages at info level or higher, # except mail system messages containing sensitive # information from authentication messages and cron daemon messages. *.info;mail.none;authpriv.none;cron.none /var/log/messages# Write messages containing sensitive # authentication information to a separate file, regardless of their level. authpriv.* /var/log/secure# All messages from the mail system should also be recorded separately. mail.* /var/log/maillog# Log the actions of the cron daemon. cron.* /var/log/cron# Emergency messages should be received immediately # by all users of the system *.emerg*# Write messages from news services at crit level and higher to a separate file. uucp,news.crit /var/log/spooler# Messages issued during the boot phase are copied to the boot.log file local7.* /var/log/boot.log |
Log file /var/log/messages
Of course, it is not possible to talk here about the contents of each line of this file. In order for the reader to get an idea of what information can be found in the protocol, we present individual message lines with very brief comments.
Each line in the log file contains a single message record, consisting of the following message fields, separated by spaces:
- date in standard text format (field TIMESTAMP from the message syslog),
- hostname (field HOSTNAME from the message syslog)
- message text (fields TAG And CONTENT from the message syslog)
First, it's worth noting that if your computer is not running 24/7, but is turned off at night, then in this file you can find records of several "work cycles" starting with the computer booting and ending with turning it off. Such a cycle begins with a message about the launch of logging daemons (this is understandable, messages were not recorded before they were launched):
Sep 17 08:32:56 kos3 syslogd 1.4-0: restart. Sep 17 08:32:56 kos3 syslog: starting syslogd succeeded Sep 17 08:32:56 kos3 kernel: klogd 1.4-0, log source = /proc/kmsg started. Sep 17 08:32:56 kos3 kernel: Inspecting /boot/System.map-2.4.2-2 Sep 17 08:32:56 kos3 syslog: starting klogd succeeded
The entries in other protocol files mentioned in the file have approximately the same structure /etc/syslog.conf.
logger and tailf commands
From the previous description we can conclude that the issuance of all messages for system logs should be specified by the programmer at the stage of program creation. This is not entirely true. The user also has the opportunity to send a message to the demon syslogd. There is a command for this in Linux logger, which allows sending a message from the command line (sh, bash, etc.). It is part of the util-linux package. Naturally, this command is primarily intended to provide logging capabilities when the user creates various kinds of shell scripts. But it can also be launched directly from the command line, for example, to familiarize yourself with the capabilities of the logging system. Command launch format: logger [-isd] [-f file] [-p PRI] [-t TAG] [-u socket] The command line options have the following meaning:
- -i- include the process number in the message
- -s- duplicate message to stderr
- -d- use datagram mode when sending messages (instead of the usual streaming)
- -f filename- save message to specified file(default is /var/log/messages)
- -p facility.level- set the category and priority of the message (default: user.notice)
- -t TAG - set the TAG field
- -u socket- send a message to the specified socket instead of calling syslogd
- MSG- Message text
Send several messages using the program logger and admire the result in the file /var/log/messages(unless you have changed the default value, of course).
By the way, there is a very interesting way to view messages written to a file /var/log/messages team logger. This method is based on the use special program tailf. Open a terminal window, get superuser rights (with the command su) and run the command in this window
tailf /var/log/messages
After that, switch to another terminal and run the command there logger free_text. Your message will immediately appear in the window where the program is running tailf. That is, with the help of this program, the system administrator can monitor the recording of new messages in the protocol in real time. True, system administrator there is hardly time to monitor the behavior of the system in this way (except perhaps emergency situations). Therefore, special programs have been developed to analyze protocols. But more about them below, but for now let’s move on to the question of how to organize surveillance of a remote computer (remember how you caught the attacker Shimomura?).
Network logging
As stated, logging system messages can be sent by the daemon syslogd to the remote host. But someone has to accept him there. It turns out that the same demon is doing this syslogd, running on this remote host. More precisely, syslogd on any computer can listen not only to the /dev/log socket (thus accepting messages from local sources), but also to port 514/UDP, which ensures that messages are received from other computers on the local network (and their subsequent recording in local file). This makes it possible to create a “logging server,” which can be very convenient for a system administrator (all events on the network are monitored in one place), and also increases network security, since messages about a hacker’s penetration of one of the network hosts cannot be immediately reported removed from the protocol by this hacker.
However, to organize such "network logging" some additional efforts must be made.
First, since port 514/UDP is used to send and receive messages over the network, it must be available on both computers (client and server). To do this in the file /etc/services the line must be present on both computers
syslog 514/udp
If such a line in /etc/services absent, syslogd can neither receive messages nor send them to the network because it cannot open the UDP port. If such a situation arises, syslogd immediately stops writing any messages, even to the local log. At the same time, as the team shows ps, it remains in memory and even stores messages in some buffers, because if the line " syslog 514/udp" restore to file /etc/services on the client, then by at least Some of the "missing" messages still appear in the log (after restarting syslogd).
Secondly, when starting the daemon syslogd the option must be specified on the server -r, which provides remote logging capabilities (default daemon syslogd waits for messages only from the local socket). How and where to set this option will be discussed below, in the section on starting the daemon syslogd.
Well, and thirdly, the settings in the files must be corrected accordingly /etc/syslog.conf on both computers. For example, if you want to redirect all messages to the logging server, you need to write in a file on the client computer /etc/syslog.conf a line like this:
*.* @hostname
If during the start of the demon syslogd the server will be unavailable (for example, it is currently disconnected from the network) or it will not be possible to find it by name (the DNS service did not work properly) syslogd makes 10 more attempts to find the server and only if after that the server cannot be found, it stops trying and sends a corresponding message.
If you have multiple domains on your network that are served by a single logging server, don't be surprised that the log on the server will include the full names of the clients (including the domain). True, at startup syslogd options can be used -s domain_list or -l host_list, which provide replacement of full host names in the protocol with their short names (without specifying the domain).
Don't forget after adjusting the launch and file options /etc/syslog.conf restart the daemon because, unlike cron, sysklogd does not reread configuration files automatically.
syslogd daemon startup options
Since we touched on the issue of setting daemon launch parameters in the previous subsection syslogd, let's look at this issue in more detail. As already mentioned, both logging daemons are launched at the system initialization stage, and more specifically, through a script /etc/rc.d/init.d/syslog(for which, as for startup scripts for other services, symbolic links are created in the /etc/rc.d/rc?.d/ directories). However, in order to set the launch parameters, there is no need to adjust this script, because starting from version 7.2 in the Red Hat distribution, the launch options for both daemons are read from a separate configuration file /etc/sysconfig/syslog. Here is a short list of possible parameters for the daemon syslogd.Launch parameters syslogd:
- -a socket- Specifies an additional socket that the daemon will listen on syslogd. You can specify up to 19 sockets (more is possible, but for this you need to recompile the package). This option is used in cases where some other daemon (for example, ftp or http) is running in a restricted environment (chrooting).
- -d- Debug mode. In this case, the demon does not go into background mode and outputs all messages to the current terminal.
- -f config-file-name Specifies the name of an alternative configuration file that will be used instead of the default one /etc/syslog.conf.
- -h Default in sysklogd It is prohibited to transfer messages received over the network to another computer. This is done to prevent endless transfers of messages around the ring. The -h option allows you to change the usual behavior and ensure that messages received from remote hosts are transmitted further over the network (and take care of possible looping yourself).
- -l host-list- Specifies a list of hosts whose names should not be written with a full domain name (FQDN - Full Qualified Domain Name); names in the list are separated by a colon.
- -m minutes Launched without this option sysklogd regularly (every 20 minutes) records category messages in the protocol mark, that is, simply time stamps. Using the option -m you can either change the interval between marks, or completely cancel the issuance of such messages, for which you need to set the interval to zero: -m 0.
- -n Do not fade into the background; this option is required in cases where syslogd is started and controlled by a process init.
- -p socket Specifies an alternative UNIX socket (instead of the default one listening /dev/log). Please note: option -a specifies additional sockets, and -p- alternative!
- -r Allow to receive messages from remote hosts. We talked about this in the previous section, so I’ll omit the details.
- -s domain-list Specifies a list of domains whose names do not need to be logged along with the host name (that is, for these domains, only the host name will be logged instead of the fully qualified domain name (FQDN). The names in the list are separated by a colon. The name of the domain in which the syslogd server is located , does not need to be included in this list (its name is removed by default).
- -v Show version and finish work.
- -x Prohibit determining a host name by its address, prevents deadlock when working on the same host with a DNS server.
After starting the daemon syslogd a status file is created /var/lock/subsys/syslog zero length, and a file with a process identification number /var/run/syslogd.pid.
Using the command
kill -SIGNAL `cat /var/run/syslogd.pid`
you can send to the demon syslogd one of the following signals:
- SIGHUP - restart the daemon (reinitialization); all open files are closed, the daemon starts again, re-reading its configuration file.
- SIGTERM - shutdown.
- SIGINT, SIGQUIT - if debugging mode is enabled (option -d), signals are ignored; otherwise, shutdown.
- SIGUSR1 - enable/disable debugging mode (works only if the daemon was started with the -d switch).
Daemon klogd has no fewer launch options than syslogd, however, we will not present them here, referring the reader to the corresponding man page (the user should not bother setting up klogd, it is better to leave it in the state in which it was produced by the distribution developers).
dmesg file and dmesg command
As already mentioned, the log files mentioned in the file /etc/syslog.conf usually located in a directory /var/log and its subdirectories. But, if we look into this directory, we will find several files there that /etc/syslog.conf were not mentioned. Let's look at their purpose. Let's start with the file dmesg.First we need to mention that Linux has a command with the same name. If you compare the output of this command (when it is run without parameters) with the contents of the file /var/log/dmesg, you will find that they are very similar, although not identical (direct the output of the command to a file dmesg2 and compare the files dmesg And dmesg2). More precisely, the file /var/log/dmesg one to one coincides with the beginning of the output that we get from the command dmesg. As follows from , the kernel has a ring buffer into which messages from the kernel logging daemon are written. Those messages that are written to this buffer during the download process constitute the contents of the file /var/log/dmesg. Apparently, this file is generated after the system boots.
If you look at the file listing provided again /etc/syslog.conf, you will see that all messages in the category kern are also issued to the console. But there they quickly run across the screen and you hardly have time to read and comprehend them. But they are saved in a file /var/log/dmesg and are thus available for leisurely reflection (if the download process is completed successfully). After the boot process is completed, writing messages from the kernel to the ring buffer continues. When the command is executed dmesg, the current state of the buffer is displayed. Therefore the output of this command contains more messages than the file /var/log/dmesg: in the output of this command you also see the messages that the kernel issues after the boot process is completed.
All messages from /var/log/dmesg you will find in the file /var/log/messages, only there they alternate with messages from other programs. There is only one significant difference: in the file dmesg the time and source of the message (hostname and message category) are not specified. The host here is always “local”, and the start of the time count is determined by the last reboot of the computer.
lastlog, wtmp and utmp files
Besides the file dmesg in the catalog /var/log/ there are two more files not mentioned in /etc/syslog.conf, but directly related to logging - these are files lastlog And wtmp. But look into them the same way we looked at the file /var/log/messages doesn't make sense - you won't understand anything. The fact is that the information in these files is recorded in a special format, and it must be viewed using special software. But first we need to say a few words about the purpose of these files.
File lastlog stores information about the user's last login. I don't know if you noticed that when you enter your username and password, something like the following message appears on the screen:
Localhost login: kos Password: Last login: Wed Oct 9 19:25:53 on tty1 These three lines are generated by the utility login, which, after determining that the user has login rights, accesses the file /var/log/lastlog, retrieves information about the user's previous successful login from there, displays it on the screen, and then updates the record in the file lastlog. You can suppress this message by creating an empty .hushlogin file in your home directory. However, it is not recommended to do this; on the contrary, you should pay special attention to the content of this message so as not to miss cases when someone else logged in under your name.
Unlike the file /var/log/lastlog, which contains time records last login for each user, in the file /var/log/wtmp are remembered All logins and logouts of users since the creation of this file. Same as in file lastlog, entries in /var/log/wtmp are made in a special format, so they can only be viewed using special commands. But before we talk about these commands, let's say that there is another file containing user logging records - this is the file /var/run/utmp. This file contains information about which users are currently working in the system.
Now you can talk about how to view information about users who are working or previously worked in the system. The main command for this is the command last. It displays all records from a file /var/log/wtmp, whereby the user name is indicated, an indication of the terminal from which the user worked, the time the user logged into the system and the time he logged out of the system, as well as the duration of the user’s session in the system. If the user's work was interrupted only because the system itself was turned off, instead of the user's exit time there is the word "down" (from these lines it is easy to determine the time the system stopped). The reboot time is displayed on separate lines starting with the word "reboot".
Team lastb like a team last, but displays information about failed user login attempts. However, it should be noted that this command will only work if the file exists /var/log/btmp. However, none of the programs discussed here create log files, so if any of them are deleted, then the recording ends.
Team lastlog formats and displays the contents of the file /var/log/lastlog. The username, terminal name from which the user logged in, and last login time will be displayed. By default (when the command is entered without parameters) the file elements /var/log/lastlog will be displayed in user ID number order. If you specify the -u login-name option, only the last login time of the specified user will be displayed. By specifying the -t days parameter, you will only receive records for the last days of days. If the user has not logged into the system at all, then instead of the terminal name and last login time, the string “**Never logged in**” will be indicated.
When executing the command lastlog On a slow computer, in some cases it may appear that the command is stuck. This occurs due to the fact that even if only two users are registered in the system (root and user), in the file /var/log/lastlog there is still room for as many users as possible to work on the system. Therefore in the file /var/log/lastlog There may be large gaps between the ID numbers of users working in the system. Because when viewing such intervals, the program does not display information on the screen, and the impression of “freezing” occurs.
To display information about who is currently working on the system, use the commands w, who And users. Team users is used when you only want to know which user is currently working in the system, but are not interested in which terminal they connected from and what they are doing. If you want to know who logged in from which terminal, use the command who. This command prints information from a file /var/run/utmp. You can force it to output data from a file /var/log/wtmp(or any other file for which it makes sense) if you specify the name of this file in command line. But in the output you will still see only the username, an indication of the terminal from which the user logged in, the login time and, in the case of login with remote computer, the name of this computer.
The command outputs significantly more information w. In its output you will see the current time, how long the system has been running, how many users are currently working in the system and the average system load for the last minute, 5 and 15 minutes. Then for each user it prints:
As already mentioned, the team w displays information stored in a file utmp. By the way, the manual man States that ordinary users must be denied write access to the file utmp, since many system programs (for some inexplicable reasons) depend on its integrity. You risk confusing system statistics files and making changes to system files if you allow any user to write to the utmp file.
Log files of other programs
In addition to the files that we have already talked about, there are other protocol files that are created by separate programs. The most typical examples are the protocols of daemons samba, ftpd or httpd, which are carried out in separate files. Some of these programs create their protocols in subdirectories of the directory /var/log/, others store protocols in other places. And the structure of these files may differ significantly from the structure of files created by the system syslog. As an example, I will give a few lines from the server protocol Apache running on my computer: 192.168.36.21 - - "GET /ve/papers/new/log/ HTTP/1.1" 200 1774 "-" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0 .0) Gecko/20020530" 192.168.36.21 - - "GET /icons/back.gif HTTP/1.1" 304 - "-" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0 ) Gecko/20020530" 192.168.36.21 - - "GET /icons/folder.gif HTTP/1.1" 304 - "-" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko /20020530" 192.168.36.21 - - "GET /icons/text.gif HTTP/1.1" 304 - "-" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530 " 192.168.36.21 - - "GET /ve/papers/new/log/protok_lovim.htm HTTP/1.1" 200 46597 "http://linux/ve/papers/new/log/" "Mozilla/5.0 (X11; U ; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530" 192.168.36.21 - - "GET /bugtraq.css HTTP/1.1" 404 279 "http://linux/ve/papers/new/log/ protok_lovim.htm" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530" 192.168.36.21 - - "GET /img/bug1.gif HTTP/1.1" 404 280 " http://linux/ve/papers/new/log/protok_lovim.htm" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530" 192.168.36.21 - - "GET /img/title.gif HTTP/1.1" 404 281 "http://linux/ve/papers/new/log/protok_lovim.htm" "Mozilla /5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530" As you can see, the structure of this protocol file is significantly different from what we saw in the system protocols.The Samba server, in addition to the main server operation protocol, creates in a subdirectory /var/log/samba a whole series of log files for different cases, in particular separate files for each of the users who are allowed to use the resources provided by this server. The following two entries are taken from one such file:
Smbd/service.c:make_connection(550) linux (192.168.36.10) connect to service public as user kos (uid=500, gid=500) (pid 1366) smbd/service.c:close_cnum(550) linux (192.168. 36.10) closed connection to service public The above examples show that if you can read a little English and have some understanding of the structure of records, you can extract a lot from log files useful information. Only it has to be extracted from entire deposits of “waste rock” - huge sequential protocol files, which is a non-trivial task. Therefore, special software tools have been developed for protocol analysis.
Tools for processing protocols
Quite a lot of different programs and scripts have been developed for analyzing protocols. I'll limit myself brief description two such means: logwatch And swatch.
logwatch is a Perl script included in the standard Red Hat Linux distribution. Just during the preparation of this article, version 4.1 of this program was posted on the developer’s website (and he is Kirk Bauer).
The main idea behind this program is that the log file is passed through a filter, which selects from the log all lines (that is, messages) that satisfy a given criterion. Results are sent by e-mail to the specified user (by default - root). Filters can be written in any programming language, but the author of the package prefers Perl. Filters must be written to read data from stdin and output the result to stdout.
Basic use logwatch consists of including a link to the main script ( /etc/log.d/scripts/logwatch.pl) to the /etc/cron.daily directory, which causes daily execution logwatch with default settings. The link is given a name that starts with "00" (eg 00-logwatch) so that the script runs before logrotate.
But you can also run the script from the command line. Of course, if you have not changed the information output parameter, then the result of its operation should be looked for in the superuser's mailbox. If you want to see these results on the screen, then you need to set the parameter on the command line --print- issue a report to stdout.
General script launch format:
/etc/log.d/scripts/logwatch.pl [--detail level ] [--logfile magazine-group ] [--service service-name ] [--print] [--mailto address ] [--save file name ] [--archives] [--range date-interval ]
The default parameters are stored in the /etc/log.d/logwatch.conf file, the comments in which help you understand the meaning of the command line parameters:
- LogDir - directory relative to which file names are considered;
- MailTo - who to send the report to;
- Print - instead of sending the report by mail, output it to stdout;
- Save - instead of sending the report by mail, save it in the specified file;
- Archives - process not only current versions logs, but also old copies created by logrotate;
- Range - process the specified time interval: All, Today, Yesterday (yesterday's calendar day);
- Detail - report detail level: from 0 to 10 or Low, Med, High;
- Service - All or filter name from /etc/log.d/scripts/services/ (several filters can be specified);
- LogFile - All or the name of a log group (several groups can be specified).
More information about the script logwatch you will find in .
The article describes another script for processing log files, which is included in the Mandrake Linux distribution. This script is called swatch(“Simple WATCHer”) and is also written in Perl.
Work management swatch carried out using a single configuration file, by default $HOME/.swatchrc. This file contains sample text (in the form regular expressions), which swatch will search in log files. Following each such example, an action is indicated that swatch must take action if it encounters text that matches the pattern.
For example, you want to be warned whenever a buffer-overflow attack is attempted on your web server when a very long file name is requested. And you know that in such cases in the log file /var/apache/error.log A message appears containing the words "File name too long". In this case, to your file .swatchrc The following instruction must be inserted:
Watchfor /File name too long/ mail [email protected], subject=BufferOverflow_attempt
I will not provide a more detailed description of the program here. swatch. An enthusiastic article is dedicated to it, and the program itself can be found on the website. I just want to point out, and swatch, And logwatch implement a rather primitive algorithm for processing protocol files, which boils down to searching the protocol for a given string of characters (signature). Meanwhile, firstly, the presence of such a line often does not indicate an intrusion by an attacker, and, secondly, a competent attacker can take care to erase traces of his activities. Another obvious drawback of the products reviewed is that they operate in “deferred mode”, since they only run on a schedule. And the fight against intruders must be carried out “in real time”, immediately responding to attempts to penetrate the system. Therefore, commercial products offer monitoring systems that operate continuously and implement “intelligent” protocol analysis algorithms. These algorithms are based on statistical analysis of message flow and identification of statistically significant deviations of the system from its normal behavior.
In conclusion of this section, I note that the website SecurityLab.ru (http://www.securitylab.ru/tools/?ID=22111) provides a list of links to the sites of various software tools for processing protocols with a brief description of these tools. You can experiment with different programs and choose the one that suits you.
Rotating log files
You, of course, understand that if the system is intensively used, then the log files grow quickly. Which results in a waste of disk space. And the problem of “taming” the protocols arises. In Red Hat Linux this problem is solved by scripts logrotate, which is located in the directory /etc/cron.daily, and therefore is launched by the daemon cron daily. This script allows you to process not only system logs syslog, but also any other programs.Script logrotate monitors the growth of log files and provides so-called rotation of these files if they exceed the specified size (or after a specified time interval). Rotation is nothing more than sequential copying of previous versions of archive files approximately as follows:
and creating a new messages file to record subsequent messages.
List of files to be processed by the script logrotate and the parameters of this processing are determined by configuration files, of which there may be several. The names of the configuration files are specified on the script launch command line (for launch parameters, see below). On Red Hat Linux, by default, the configuration files for logrotate file is used /etc/logrotate.conf, which might look something like this:
Weekly rotate 4 create compress include /etc/logrotate.d /var/log/wtmp /var/log/lastlog ( monthly create 0664 root utmp rotate 1 )
This file is like any configuration file for a script logrotate consists of several sections. The first section defines global parameters (one per line) that set default parameters for all logs. The following sections define local parameters for a series of log files. The names of these files are listed in the first line of the section, and then local parameters are specified in curly braces, which are valid only when processing the specified files (also one parameter per line). Log file names can be quoted according to shell rules if they contain spaces or other special characters. You can specify multiple file names or file name patterns separated by spaces (patterns also follow shell rules). Processing each section is treated as a single action. Lines starting with the "#" symbol are comments. Local parameters take precedence over global ones.
The example configuration file first describes global parameters, and then, in a separate section, parameters for processing the /var/log/wtmp and /var/log/lastlog files. In addition, among the global parameters a link to the directory is given /etc/logrotate.d, in which each package writes local parameters for its logs.
In the global parameters section, you first set one of the following parameters that determine the file rotation criterion:
and parameter include, followed by the name of another (additional) configuration file or even the name of a directory. In the latter case, all files in the specified directory, except for subdirectories, special files and files with suffixes from the list of exceptions, are considered configuration files for the script logrotate(directive include cannot be used inside a section that specifies processing parameters for a group of files).
Parameter rotate number can be found among both global and local parameters and determines how many old versions should be stored; if the number is 0, then archived versions of the protocol are not created.
If the parameter is specified compress, then older versions are compressed using gzip, and if specified nocompress- they don’t shrink. Parameter compresscmd allows you to specify which compression program will be used (gzip by default), and uncompresscmd specifies the decompression program (default - ungzip). compressoptions sets compression program parameters; the default is "-9", i.e. maximum compression for gzip. Using the parameter compressext you can change the suffix for compressed files, and the extension suffix specifies the suffix added to file names during rotation (before the compression suffix).
Among keywords, found in configuration files, we should especially note the words postrotate And prerotate, which serve as opening parentheses for inclusion in shell script configuration files. All lines of the configuration file from the line postrotate to line endscript are executed as shell commands after the process of changing the log file version. Accordingly, all lines from the line prerotate to line endscript are executed before the log files are rotated. Using these scripts, you can organize various procedures for processing log files during rotation.
Using other parameters of the configuration file, you can redefine access rights to log files (if this parameter is not specified, then the attributes of the old log file are used); indicate to whom to send messages about errors in the functioning of the logging system; send an archived copy of the log to the specified user; set the directory to which logs will be moved during version changes (the directory must be on the same physical device as /var/log) or set a list of exclusion suffixes for the directory include. Detailed description You will find these features and parameters (as well as those that were not mentioned) with the command man logrotate.
As already mentioned, additional configuration files logrotate can be specified on the script launch command line. You can specify an arbitrary number of configuration file or directory names. The names of files and directories in this list are separated simply by spaces. The order in which names are listed matters because the options listed in the following configuration file, overlap the values of the parameters specified in previous file. The order of files in the configuration directory is not defined.
In addition, you can specify the following parameters on the startup command line:
- -d- debug mode, no real changes are made,
- -f- make changes, even if logrotate does not see the need - is used when there are changes in the list of processed logs,
- man logwatch
- Mick Bauer, "Paranoid Penguin: swatch: Automated Log Monitoring for the Vigilant but Lazy"
- RFC 3164. C. Lonvick, The BSD Syslog Protocol, August 2001.
- RFC 3195. D. New, M. Rose, Reliable Delivery for syslog, November 2001.
- Per. S. Lapshansky, “The demon is watching the system”
- Denis Kolisnichenko,
The actions of the syslogd daemon are controlled by the /etc/syslog.conf configuration file. This is a simple text file in which empty lines and lines with a # in the first position are ignored. The file format is as follows:
<селектор> <действие>.
For example,
mail.err /var/log/mail.errors
This line will ensure that all mail delivery errors are recorded in the /var/log/mail.errors file.
Important: Use only the key as a separator between the selector and the action
As you have already noticed, the selector is written in a composite form. IN general view it looks like a means.level
Moreover, in the field<селектор>may contain one or more selectors, separated by semicolons. A selector can contain a group of facilities separated by commas. The selector can contain the characters * and none, which mean "all" and "nothing" respectively.
Selector examples:
means. level of action
means 1, means 2. level of action
means 1. level 1; means 2. level 2 action
*.action level
*.level;means.none action
The following tables list the main syslog feature names and severity levels.
Tool Programs that use it
kern System kernel
user User processes
mail Email system
daemon System daemons
auth Security and Authority Systems
lpr Printing system
news Teleconferencing system
cron The cron daemon
local0-7 Eight levels of local message
syslog Internal syslog system messages
ftp ftpd daemon
*All of the above means
Level Level value
emerg Emergency situations
alert Urgent situations
crit Critical states
err Error conditions
warning Warnings
notice Unusual conditions
Info Information messages
debug Debugging information
The levels are listed in descending order. This means that the levels indicate the minimum importance that a message must have in order to be logged in the syslog system.
Field<действие>indicates what to do with the received message.
Action Description
filename Write the message to a file on the local machine
@machinename Forward a message to the syslogd daemon on the specified machine
@IP_address The same, only the IP address of the machine is specified
user1, Display a message on the screens of the specified users...
userN
* Display a message on the screens of all users
*.emerg /dev/console
*.err;auth.notice /dev/console
*.err;auth,mail,user.info /var/log/messages
mail.err /var/log/mail.log
mail.info @192.168.0.1
Speaking of the syslog system, we need to mention the logger command, which allows you to write entries to the system log from shell scripts.
This command is useful for checking changes made to the /etc/syslog.conf file.
local5.warning /var/log/local.log
and want to check if it works, then enter the command
# logger -p local5.warning "Local test"
Look at the /var/log/local.log file. If the "Local test" line is not there, then you most likely forgot to send the HUP signal to the syslogd daemon.
SERGEY SUPRUNOV
FreeBSD tips: using syslog
- Excuse me, comrades, I have all the moves written down!
“The office writes,” said Ostap.
I. Ilf, E. Petrov “12 chairs”.
Logging the operation of any system, and especially the server, is one of the most important components of administration. It is the log files that we look at first when problems arise in the system. From there we gain confidence that this or that program works as expected. When developing web applications, the log file becomes the most important source of debugging information. The features of the syslog daemon, which is responsible for logging system information, will be discussed.
What is syslog
Syslog is a centralized service that collects and records log information from various operating system components and user processes. Third-party programs, as a rule, can work with their log files independently, although many of them can be configured to work with the syslogd daemon. The benefits of using syslog include the ability to manage the collection of necessary information using a single configuration file, which ensures consistency in the resulting log files and ultimately simplifies their management.
The syslog service is provided by the syslogd daemon, which is automatically launched at system startup. It resides in memory constantly, waiting for messages from other processes and processing them according to its settings.
Each message is characterized by a level and a source (facility). The level specifies the degree of importance of the message from the point of view of system operation. The syslog.h file defines the following levels (priorities):
Table 1. Message levels
|
Level |
Description |
|
emerg, panic |
State of "panic" |
|
alert |
Condition requiring immediate intervention |
|
crit |
Critical condition |
|
err, error |
Other operating errors |
|
warning, warning |
Warnings |
|
notice |
Messages that are not errors but that you should pay attention to |
|
info |
Information messages (normal operation) |
|
debug |
Debug information |
Table 1 lists message levels in descending order. This order will be needed later when discussing configuration file syntax.
Message level designations written on the same line (for example, emerg and panic) are synonyms, and either one can be used. However, panic, error, and warn (listed second in the table) are deprecated and should be avoided when editing the configuration file. Instead, use emerg, err and warning respectively.
Possible message sources are listed in Table 2:
Table 2. Message sources
|
Source |
Description |
|
kern |
Kernel messages |
|
auth, authpriv |
|
|
security |
Security messages (for example, from firewall) |
|
console |
Messages coming to the console (/dev/console) |
|
syslog |
Native syslog messages |
|
cron |
Cron Messages |
|
Time service messages |
|
|
Messages FTP servers |
|
|
Print subsystem messages |
|
|
|
Postal service messages |
|
news |
News Service Messages |
|
uucp |
Messages UUCP |
|
daemon |
Messages from other daemons running in the system |
|
user |
User Process Messages |
|
local0 – local7 |
Can be used for various user needs (sometimes used by the system) |
When configuring an application to use the syslog service, check which facility it uses. Some programs allow you to specify the source yourself. For example, the clamd daemon (the main process of the clamav antivirus) uses local6 by default, but allows you to specify a different source (the LogFacility parameter in the configuration file). In some cases, it may be useful to combine its messages with messages from mail services, specifying LOG_MAIL as the source.
Daemon launch options
For a complete list of startup options, see the syslogd man page. Here we will consider only a few of them.
Syslog is capable of recording incoming messages to log files (which are usually located in the /var/log directory), sending them to the user's console or connected terminal, sending them to a remote host, or sending them to an external utility for processing via a pipeline.
To work over the network, syslog uses ports 514 (UDP and TCP). When run without additional parameters, syslogd will listen on these ports, waiting for incoming messages. The -s switch prevents incoming messages from being accepted, but sockets on port 514 are still created for outgoing connections so that syslogd can send messages to remote hosts. Doubling the switch (-ss) also disables outgoing connections.
By default, syslogd is started with the -s switch (see /etc/defaults/rc.conf, syslogd_flags parameter), so incoming connections are prohibited. If you want to use your server's syslog service to serve multiple machines, add the following line to /etc/rc.conf:
syslogd_flags= ””
This will override the value set in /etc/defaults/rc.conf and syslogd will be able to service incoming connections. Naturally, in this case it is necessary to ensure the required level of security, eliminating the possibility of other hosts writing anything to your logs. The -a switch allows you to set restrictions on incoming connections (see man syslogd). A properly configured firewall also plays an important role.
Another useful switch -l allows you to specify additional socket files that the syslogd daemon listens to in addition to the default /var/run/log. For example, this key is required so that syslog can serve programs running in a chrooted environment. In particular, this is how named works, starting with BIND 9. In FreeBSD 5.3, syslogd is started with the following keys:
#ps-wax | grep syslog
| 321 ?? Ss 0:01.67 /usr/sbin/syslogd -l /var/run/log -l /var/named/var/run/log -s |
Configuration file syntax
Logging is configured in the /etc/syslog.conf file. It goes without saying that only the root user can edit it. This file contains two types of strings – let’s call them “filters” and “rules”.
The filter line specifies the program or host from which the following rules will be applied to messages from it. A filter of the form “!prog” (or “#!prog”) indicates that the following lines refer to logs that are generated by the specified prog program. A synonym for this entry is “!+prog”. The "!-prog" line, on the other hand, indicates that subsequent rules will apply to all messages except those originating from the prog program. It is allowed to list several programs separated by commas, while the “+” or “-” sign applies to the entire list.
If the filter string is specified as "+hostname", then the specified host will be used as the source of messages that should be processed by subsequent rules. As with programs, the “-” symbol indicates that the rules will apply to all messages except those coming from the specified host. You can specify a list of hosts separated by commas.
The "*" character specified as a program or host will override the filter that was previously set. That is, the rules specified after such a line will apply to all messages. Filters with host or program name are independent of each other and can operate simultaneously. For example:
# The rules located here apply to all messages
My.host
# The rules apply to all messages from my.host
Logger
# Rules are applied to messages from logger from my.host (the host filter remains in effect)
# Rules apply to messages from su to my.host
# The rules apply to messages from su from any host (the host filter is canceled, the program filter continues to operate)
# The rules apply to all messages (the program filter is also canceled)
The rule lines look like this:
facility.CMPlevel destination
Here facility is the source of the message (“*” denotes any sources), level is the level of messages that will be processed in accordance with this rule. The service word “none”, specified instead of the level, gives instructions to completely exclude messages from this source.
CMP – comparison operation (symbols “>”, “” are allowed<», «=», «>=», «<=», а также символ отрицания «!»). Если символ сравнения не указан, подразумевается «больше или равно», то есть обрабатываются все сообщения уровня level и выше.
Destination specifies where this message should be saved. This can be a log file (the full path is indicated, starting with “/”), a remote server address (starting with the “@” symbol), a user name (messages will be sent to the terminal to which the user is connected). The message can also be transferred to an external program for processing, for which the conveyor symbol “|” is used.
Some examples of rules
All kernel messages will be sent to the kern.log file.
kern.* /var/log/kern.log
All error messages, as well as emerg, alert and crit level messages, will be placed in all-err.log. Note the hyphen before the log file name. By default, messages are buffered in memory and written to disk when the buffer is full. This reduces the load on the file system, but may cause the loss of some information if the machine crashes. The hyphen before the file name causes the syslogd daemon to immediately write messages to disk.
*.err -/var/log/all-err.log
Debugging messages for user processes will be output to the terminal to which user vasya is currently connected.
user.debug Vasya
All messages from news and email services will be forwarded to port 514 of the syslog.host.ru machine.
mail.*,news.* @syslog.host.ru
All print service messages whose level is lower than warning will be placed in the specified file. As stated earlier, the default comparison is "greater than or equal to" and the "!" inverts it, replacing it with “less”. If you need to exclude a specific level, you should use the “!=” construction.
lpr.!warning /var/log/printers.log
debug level (and only this) messages with facility level0 and level3 will be output to all connected terminals.
level0,level3.=debug *
Time service messages that are higher than critical (that is, emerg and alert) and less than or equal to notice (notice, info, and debug) will be sent to the ntpuser and root user terminals.
ntp.>crit,<=notice ntpuser,root
All warning level messages, excluding those coming from mail services, will be recorded in the warn.log file.
*.=warning,mail.none /var/log/warn.log
In this case, all messages whose level is greater than or equal to crit will be sent by email to the root user.
*.crit | mail -s “critical message” root
As you can see, the configuration file format allows multiple levels, sources, and destinations to be listed on one line, making configuration more flexible. For changes after editing to take effect, you need to send a HUP signal to the syslogd process:
# kill –HUP `cat /var/run/syslog.pid`
It should be noted that if a message falls under several lines in the configuration file, then it will be processed in accordance with each of them. Example:
mail.* /var/log/maillog
*.=err /var/log/error.log
In this case, mail.err messages will end up in both maillog and error.log.
Strategy for creating a configuration file
Concluding our review of the configuration file, I will say a few words about the strategies for compiling it. In addition to the very popular “as long as it works,” we can distinguish two main ones, which we will roughly call “by source” and “by purpose.”
- The first strategy, which can be seen in a number of GNU/Linux distributions, is to write a different rule for each message source (or a group of rules if messages at different levels should be processed differently). Its advantage is the ease of determining where messages from specific services are recorded.
- The "by destination" strategy involves creating, if possible, only one line for each "recipient" of a message, such as a file. This approach is followed, in particular, by FreeBSD. As a result, you can easily determine what information is written to a particular log file, but, for example, destinations for kernel messages have to be collected throughout the configuration file.
Logger utility
The system includes a logger utility that allows you to send messages to the syslog service directly from the command line. It is convenient to use when testing configuration rules, as well as in developed scripts for logging their operation. Examples:
user$ logger -p user.err “Error in user program!”
user$ logger -h syslog.host.ru “Test it”
The first example will send a message with facility user level err, which will be processed according to the configuration file. The second command will send a message to the remote host, the default source and level will be set to user.notice.
Using rotation mechanisms
The logging mechanism discussed above does not provide any management of log files. Messages are simply placed in them according to the rules described in the configuration file. This means that the log files will constantly grow, and if nothing is done, they will sooner or later fill all the available space of the corresponding partition. To avoid this, a rotation mechanism is used.
For example, once the size of the debug.log file exceeds 100 MB, it is renamed debug.log.0 and packaged into debug.log.0.bz2. And instead, a new debug.log is created. Next, when the size of the new file reaches 100 MB, debug.log.0.bz2 is renamed to debug.log.1.bz2, and the procedure described above is repeated. The system stores only a certain number of archive files, deleting the oldest ones. This is rotation.
newsyslog utility
On the FreeBSD system, the newsyslog utility is responsible for rotation, which by default is launched at the beginning of every hour by the cron daemon. You can change the rotation period by editing the /etc/crontab.
The rotation parameters indicated in the above example (file size, packaging), as well as a number of others, are set in the /etc/newsyslog.conf configuration file. For each file that needs to be rotated, it contains a line of generally nine fields: file name, owner and group, access rights, highest number in the archive file name, maximum file size, rotation period, additional flags, and path to The PID file of the application to which the signal needs to be sent after rotation, and the number of the signal that should be sent. (Sending a signal to the process may be necessary, for example, if the process keeps the log file open at all times; if this is not done, the file descriptor used will not match the newly created file.) Some fields may be omitted. Here are two examples, complete and “typical”:
/var/log/pflog root:wheel 600 3 100 * JB /var/run/pflog.pid 1
According to this rule, the pflog file should be overwritten as soon as its size exceeds 100 MB (5th field) regardless of the time (the “*” character in the 6th field). Archived files will have names like pflog.X.bz2 (pflog.0.bz2, pflog.1.bz2, etc.), and X cannot be more than three (parameter 3 in the 4th field). The J flag indicates that the archive file should be packaged using the bzip2 utility. Thanks to the B flag, rotation service messages will not be added to archived and newly created files, since the file is perceived as binary. The newly created file will be owned by the root user and the wheel group (this field could be omitted since this is the default owner). The permissions will be set to rw------- (numeric value 600), meaning only the owner will be able to read and write to this file. Finally, a signal 1 (HUP) will be sent to the process whose PID is stored in /var/run/pflog.pid to re-open its log file.
/var/log/maillog 640 7 * @T00 J
This rule specifies the rotation parameters for the maillog file: regardless of the size (asterisk in the 5th field), the file will be rewritten every night at 00:00 (in man newsyslog.conf the time format is described in sufficient detail). The archive must be packed, the last 8 archives (numbered 0 to 7 inclusive) will be saved, the newly created file will be owned by the root user (default value, so the owner field is skipped) and have the permissions rw-r-----.
To view packed log files, you can use the zcat and bzcat utilities (for gzip and bzip2, respectively). Midnight Commander calls the appropriate utilities automatically.
After editing the newsyslog.conf file, no signals need to be sent anywhere - the configuration will be re-read the next time newsyslog is called.
It should be noted that the newsyslog utility is not tied to the syslogd daemon. That is, it can be used to rotate any files that need it. If rotation is enabled for logs that the application maintains independently (for example, clamd or squid logs), then be especially careful about specifying the owner and access rights. Specifying them incorrectly may result in the fact that after rotation, an application running as an unprivileged user will not be able to write to the newly created file.
Summing up
The syslog system is a very powerful and effective tool for logging various events occurring in the system. The default settings are fairly balanced and work well for most systems. However, understanding how syslog works will allow you to significantly improve the quality of logging by customizing the recording of log information strictly in accordance with your needs.
