{"id":221,"date":"2020-08-18T19:23:47","date_gmt":"2020-08-18T20:23:47","guid":{"rendered":"http:\/\/www.linux-tutorial.info\/?page_id=77"},"modified":"2020-08-22T19:26:39","modified_gmt":"2020-08-22T20:26:39","slug":"this-is-the-page-title-toplevel-56","status":"publish","type":"page","link":"http:\/\/www.linux-tutorial.info\/?page_id=221","title":{"rendered":"Syslogd"},"content":{"rendered":"\nSyslogd<\/title>\n<p>\nThe workhorse of the Linux logging system is the system logging <glossary>daemon<\/glossary>\nor syslogd. This daemon is normally started from the system start-up (rc) scripts when the\nsystem goes into <tutorial id=67>run level 1<\/tutorial>.\nOnce running, almost any part of the system, including applications, drivers, as\nwell as other daemons can make log entries. There is even a command line\ninterface so you can make entries from scripts or anywhere else.\n<p>\nWith Windows NT, each system maintains its own log files. There is no central\nlocation where they are all stored. Although the Event Viewer can access\nevent logs on other machines, this can often take a\ngreat deal of time especially when there are a lot of entries and you have a\nslow connection.\n<concept id=\"\" description=\"Syslogd can be configured to sent all or just of its messages to a remove machine.\" \/>\n<question id=\"\" type=\"tf\" text=\"Syslogd can be configured to sent all or just of its messages to a remove machine.\" \/>\n<\/p>\n<p>\nInstead, <command>syslogd<\/command> can be configured to send all (or just some) of the messages\nto a remote machine, which\nprocesses them and writes them to the necessary files. It is thus possible that\nall the log messages of a particular type from all machines in your network\nare stored in a single file, which make accessing and administering them much\neasier.\n<concept id=\"\" description=\"Syslogd writes messages in text files, which can be read by scripts.\" \/>\n<question id=\"\" type=\"tf\" text=\"Syslogd writes messages in text files, which can be read by scripts.\" \/>\n<p>\nAnother advantage is due to the fact that <command>syslogd<\/command>\nstores configuration information and log entries in text files. Therefore, it is a simple matter of writing a script that parses the entries and splits them into separate files, or processes them in other ways.\n<concept id=\"\" description=\"Syslogd writes messages in a standard format: date time system facility message\" \/>\n<question id=\"\" type=\"mc\" text=\"What is the standard format in which syslogd writes messages?\" \/>\n<p>\nPart of this ability lies in the standard format of each log entry. Although\nit is possible that a rogue program could write information in any order,\nall system daemons and most programs follow the standard, which is:\n<p>\n<filecontents>\ndate time system facility message\n<\/filecontents>\n<\/p>\n<concept id=\"\" description=\"The 'facility' of a syslog message is a component of the system generating the message.\" \/>\n<question id=\"\" type=\"tf\" text=\"Only system programs and services can write to the system logger.\" \/>\n<p>\nHere “system” is the <glossary>host<\/glossary>\nname which generated the message. The “facility” is a\ncomponent of the system generating the message. This could be anything like\nthe <glossary>kernel<\/glossary>\nitself, system daemons and even user applications. Finally, there is\nthe text of the message itself. Here are two messages on the system jupiter.\nOne is from syslogd and the other from the kernel:\n<p>\n<screenoutput>\nJun 5 09:20:52 jupiter syslogd 1.3-0: restart.\n<\/screenoutput>\n<p>\n<screenoutput>\nJun 5 09:20:55 jupiter kernel: VFS: Mounted root (ext2 file system) readonly.\n<\/screenoutput>\n<p>\nAs you can see, even if you could not separate\nthe log entries into different files, it would be fairly easy to separate\nthem using a script.\n<p>\n<b>Configuring syslogd<\/b>\n<p>\nWhat is done and when it is done is determined by\nthe <command>syslogd<\/command> configuration file, <file type=\"\">syslog.conf<\/file>,\nwhich is usually in <directory>\/etc<\/directory>. (I\nhave never seen it anywhere else.) This is a typical Linux configuration file\nwith one item (or rule) per line and comment lines begin with a pound-sign\n(#). Each rule consists of selector portion, which determines the events to\nreact to and the action portion, which determines what is to be done.\n<\/p>\n<concept id=\"\" description=\"A system message is broken into two parts: facility and priority\" \/>\n<concept id=\"\" description=\"A dot (.) is used to seperated the facility and priority (selector) in syslogd.conf.\" \/>\n<question id=\"117\" text=\"A system message is broken into what two parts?\" \/>\n<question id=\"\" type=\"mc\" text=\"What character is used to seperated the facility and priority (selector) in syslogd.conf?\" \/>\n<p>\nThe selector portion is itself broken into two parts, which are separated by\na dot. The facility part says what aspect of the system is to be recorded and\nthe priority says what level of messages to react to. The selector has the\ngeneral syntax:\n<p>\n<filecontents>\nfacility.priority\n<\/filecontents>\n<p>\nYou can see a list of facilities in table 1 and a list of the priorities in\ntable 2.\n<question id=\"\" type=\"mc\" text=\"Which of the following is not a syslog facility?\" \/>\n<p>\nTable 1<br \/>\nauthpriv <br \/>\ncron <br \/>\ndaemon<br \/>\nkern<br \/>\nlpr<br \/>\nmail<br \/>\nmark<br \/>\nnews<br \/>\nsecurity<br \/>\nsyslog<br \/>\nuser<br \/>\nuucp<br \/>\nlocal0 through local7.\n<br \/>\n<\/p>\n<concept id=\"\" description=\"The 'security' syslog facility should no longer be used.\" \/>\n<p>\nThe facility “security” should no longer be used and the “mark” facility is\nused internally and should not be used within applications. The facilities\nlocal0 through local8 are intended for local events on you local system when\nthere is no other applicable facility.<\/p>\n<\/p>\n<question id=\"119\" text=\"What is the highest priority for the system logger daemon?\" \/>\n<question id=\"\" type=\"mc\" text=\"Which of the following is not a syslog priority?\" \/>\n<question id=\"\" text=\"What is the lowest priority for the system logger daemon?\" \/>\n<p>\nTable 2 – Syslogd Priorities in increasing significance<br \/>\ndebug<br \/>\ninfo<br \/>\nnotice<br \/>\nwarning or warn<br \/>\nerr or error<br \/>\ncrit<br \/>\nalert<br \/>\nemerg or panic<br \/>\n<p>\nThe priorities error, warn and <glossary>panic<\/glossary>\nare deprecated and should no longer used.\n<\/p>\n<\/p>\n<question id=\"\" type=\"mc\" text=\"An asterisk (*) character is used as a wildcard for either the facility and priority in syslogd.conf.\" \/>\n<question id=\"\" type=\"mc\" text=\"What character is used as a wildcard for either the facility and priority in syslogd.conf?\" \/>\n<question id=\"\" type=\"tf\" text=\"For security reasons you must explicitely specify the priority for messages in syslog.conf.\" \/>\n<p>\nFor both facilities and priorities there is a “wildcard” that can be\nused (an asterisk – *) which means any facility or any priorities. For\nexample, *.emerg would mean all emergency messages. mail.* would mean all\nmessages coming from the mail facility. Logically, *.* means all priorities of\nmessages from all facilities.\n<\/p>\n<concept id=\"\" description=\"The word 'none' is used to refer to no priority for the specified facility.\" \/>\n<question id=\"\" type=\"TF\" text=\"The word 'none' is used to refer to no priority for the specified facility.\" \/>\n<p>\nThe word “none” is used to refer to no priority for the specified facility.\nFor example, the selector mail.none would say not to perform the action for\nany mail <glossary>event<\/glossary>.\nAt first, this might not make sense. Why not simply leave off that facility?\nThe answer lies in the previous paragraph. Using the <glossary>wildcard<\/glossary>,\n you could say\nthat all info messages were to be logged to a certain file. However, for\nobvious reasons, you want all of the <glossary>security<\/glossary>\n(regardless of the priority) written to another file.\n<p>\n<concept id=\"\" description=\"A comma is used to separate a list of facilities in syslog.conf.\" \/>\n<question id=\"\" type=\"mc\" text=\"What character is used to separate a list of facilities in syslog.conf?\" \/>\n<question id=\"\" type=\"tf\" text=\"You can create a sub-set of facilities reported by syslogd by using a comman separated list.\" \/>\n<p>\nAnother possibility is to specify a sub-set of facilities, rather than\nall of them. This is done by separating the facilities with a comma and then\nthe priority follows the last facility listed. For example, to refer to\ninformation messages for mail, uucp and news, the selector entry would look like\nthis:\n<p>\n<filecontents>\nmail,uucp,news.info\n<\/filecontents>\n<\/p>\n<question id=\"\" type=\"tf\" text=\"When you specify a syslog priority you actually mean anything at that level or higher.\" \/>\n<question id=\"\" type=\"tf\" text=\"To specify multiple priorities you must list them seperately.\" \/>\n<concept id=\"\" description=\"When you specify a syslog priority you actually mean anything at that level or higher.\" \/>\n<p>\nOne thing I need to point out here is that when you specify a priority, you\nare actually specifying everything at that priority or *higher*. Therefore,\nin this example, we are selecting all of the priorities at info and higher.\n<\/p>\n<concept id=\"\" description=\"There are generally three things you can do with syslog messages: write them to a file, send them to another machine and notify users.\" \/>\n<question id=\"\" type=\"mc\" text=\"What three things you can typically do with syslog messages?\" \/>\n<concept id=\"\" description=\"Since Linux treats them like files, syslog messages can be sent to device files like the system console.\" \/>\n<question id=\"\" type=\"tf\" text=\"Since Linux treats them like files, syslog messages can be sent to device files like the system console.\" \/>\n<p>\nThere are three primary things you can do with these events (the actions).\nProbably the most common action is to write them to a file. However, there is\nmore to this than it appears. Remember that Linux (as well as other UNIX\ndialects) treat devices as files. Therefore, you can send the logging\nmessages to a specific device.\n<p>\nHere, I not talking about sending them to a tape drive (although that might not\nbe a bad idea). Instead, I am talking about something like the system console\n(<device>\/dev\/console<\/device>). It is a common practice to send emergency messages to the\nsystem console, where someone will see the\nmessages no matter to what console <glossary>terminal<\/glossary>\nthey are logged on. In other cases,\nkernel messages are sent to one of the <command>console<\/command> terminals (e.g. <device>\/dev\/tty7<\/device>).\nYou might end with something like this:\n<p>\n<filecontents>\nkernel.*\t\t\/dev\/tty9\n<\/filecontents>\n<p>\nWhen writing to files, you want to consider that the system will actually\nwrite the information to the disk with each <glossary>event<\/glossary>.\nThis ensures the entry actually makes it to the file if the system should\n<glossary>crash<\/glossary>. The problem is that\nwriting to the harddisk takes time. That’s why the system normally saves up\na number of writes before sending them all to the disk.\n<p>\n<question id=\"\" type=\"mc\" text=\"What character is used to tell syslogd not to 'sync' each time it\nwrites the logs?\" \/>\n<concept id=\"\" description=\"The minus-sign used to tell syslogd not to 'sync' each time it\nwrites the logs.\" \/>\n<p>\nIf overall system performance becomes an important factor in regard to\nlogging, you can tell syslogd <strong>not<\/strong> to <command>sync<\/command> the disk each time it writes to a log file. This is done by putting a minus sign (-) in front of the file\nname, like this:\n<p>\n<filecontents>\nlpr.info \t-\/var\/adm\/printer.log\n<\/filecontents>\n<p>\nIf you disable syncing the log file like this, one important thing to remember\nis that you stand the chance of losing information. If the system goes down\nfor some reason before the information is written to the file, you may lose\nan important clue as to why the system went down. One solution would be to\nhave a central log server where all of the information is sent and where you\ndo <b>not<\/b> disable syncing. That way no matter what, you have a record of what\nhappened.\n<question id=\"425\" text=\"Messages can be sent to the system logger daemon on other machines.\" \/>\n<concept id=\"64\" description=\"Messages can be sent to the system logger daemon on other machines.\" \/>\n<concept id=\"207\" description=\"System messages can be sent to the system logger daemon on an other machines.\" \/>\n<p>\nSending the log messages to another machine is done by using an at-sign (@)\nin front of the machine name as the action. For example:\n<\/p>\n<p>\n<filecontents>*.emerg\t\t\t@logserver<\/filecontents>\n<\/p>\n<p>\nThis sends all emergency message to the machine logserver. I would suggest\nthat you do not create a log server that is connected to the Internet. A\nill-intended person might be able to bring the system to a halt or at least\naffect its performance by flooding it with erroneous log messages.\n<\/p>\n<p>\nAnother useful feature is the ability to send messages to named pipes. This\nis done by preceding the name of the <glossary>pipe<\/glossary>\nby the pipe-symbol (|). I find\nthis a useful way of sending log messages to other programs, where I can\nprocess them further. Named pipes are created using the <command>mkfifo<\/command>(1) command and\nmust exist prior to <command>syslogd<\/command> starting.\n<\/p>\n<concept id=\"\" description=\"You can configure syslogd to send notifications to any user when specific messages arrive.\" \/>\n<question id=\"\" type=\"tf\" text=\"You can configure syslogd to send notifications to any user when specific messages arrive.\" \/>\n<question id=\"\" type=\"tf\" text=\"You can configure syslogd to send notifications only to the root user when 'emergency' messages arrive.\" \/>\n<question id=\"\" type=\"tf\" text=\"You can only send notifcations to a user as a result of syslog.conf entries if they are logged in.\" \/>\n<concept id=\"\" description=\"You can only send notifcations to a user as a result of syslog.conf entries if they are logged in.\" \/>\n<p>\nAnother action is the ability to send notification messages to particular users, provided\nthey are logged in at the moment. To do this you simply put their username as\nthe action. To send it to multiple users, separate the names by a comma.\nThis might give you something like this:\n<p>\n<filecontents>*.emerg\t\t\troot,jimmo<\/filecontents>\n<\/p>\n<p>\nNote that you could create an action that generates an email message which the user receives if they are logged in or not. However, that is not what we are talking about here.\n<\/p>\n<concept id=\"\" description=\"Using a wildcard for the user name in syslog.conf, you can send a message to all logged-in users.\" \/>\n<question id=\"\" type=\"tf\" text=\"Using a wildcard for the user name in syslog.conf, you can send a message to all logged-in users.\" \/>\n<p>\nBy using an asterisk in place of the list of user names, you can send a message to everyone logged in.\n<\/p>\n<concept id=\"\" description=\"You cannot specify multiple actions in a single entry in syslog.conf.\" \/>\n<concept id=\"\" description=\"To specify multiple actions in syslog.conf for any given type of message you must create separate rules for each action.\" \/>\n<question id=\"\" type=\"\" text=\"You cannot specify multiple actions in a single entry in syslog.conf.\" \/>\n<p>\nIn some cases, you want multiple actions for a specific facility or priority.\nThis is no problem. You simply create multiple rules. One common example is\nbroadcasting all of the emergency messages to every user, as well as writing\nthem to a log file <em>and<\/em> sending them to another server in case the local\nmachine crashes. This might be done like this:\n<p>\n<filecontents>\n*.emerg\t\t\t\/var\/adm\/messages<br \/>\n*.emerg\t\t\t*<br \/>\n*.emerg\t\t\t@logserver<br \/>\n<\/filecontents>\n<\/p>\n<concept id=\"\" description=\"You can have both different facilities and different priorities for a single rule in syslog.conf by separating the entries by a semi-colon.\" \/>\n<question id=\"\" type=\"mc\" text=\"What character would you use to have both different facilities and different priorities for a single rule in syslog.conf?\" \/>\n<p>\nPreviously, I mentioned the ability to cause a single action based on the\nsame kind of messages for multiple facilities. This is still an example of a\n<em>single<\/em> selector resulting in a specific action. Taking this one step\nfurther, you might want multiple selectors all to result in a specific\naction. Although it could be done with multiple rules, it possible to have\nmultiple selectors all on the same line. This is done by separating the\nselectors with a semi-colon (;).\n<p>\n<filecontents>\n*.emerg;kernel.critical\t\t\troot,jimmo\n<\/filecontents>\n<p>\nThis would notify the users root and jimmo for all emergency messages as well\nas critical messages from the <glossary>kernel<\/glossary>\nfacility.\n<\/p>\n<concept id=\"\" description=\"By using an equal sign(=) in front a priority in syslog.conf, you tell it to perform that action for messages at that priority only and none above.\" \/>\n<question id=\"\" type=\"mc\" text=\"What character would you use in front a priority in syslog.conf, you tell it to perform that action for messages at that priority only and none above?\" \/>\n<p>\nThe Linux syslogd has added a couple of functions that are not available in\nother versions of <glossary>UNIX<\/glossary>.\n By preceding a priority with an equal-sign (=), you\ntell syslogd only to react to that one priority. This is useful since\n<command>syslogd<\/command> normally reacts to everything with that priority and higher. One place\nwhere this is useful is when you want all debugging messages to be logged to\na specific file, but everything logged to another file.\n<concept id=\"\" description=\"By using an exlamantion mark (!), you can exclude specific prioties in syslog.conf.\" \/>\n<question id=\"\" type=\"mc\" text=\"What character would you use to exclude specific priorities in syslog.conf.\" \/>\n<p>\nYou can also explicitly exclude priorities by preceding them with\nan exclamation mark. Note that this will exclude the priorities listed as well\nas anything higher. You can combine the equal-sign and exclamation mark\nequal-sign and exclamation mark and therefore exclude a specific priority. If\nyou do so, you need to precede the equal sign with the exclamation mark as\nwhat you are saying is not to include anything that equal a particular\npriority.\n<p>\nAll of these features can be combined in many different ways. For example,\nyou can have multiple selectors, which include as well as exclude specific\npriorities. For example:\n<p>\n<filecontents>*.warn;mail.=info;lpr.none;uucp.!crit \t\t\/dev\/tty07<\/filecontents>\n<p>\nThis would send warning messages from all priorities to the system console\nterminal \/dev\/tty7, plus the mail log messages at only the info priority, no\nprinter messages at all, and finally excluding just the uucp critical\nmessages. Granted this is a rather contrived example, but it does show you\nhow complex you can get.\n<\/p>\n<concept id=\"\" description=\"The last matching component for rules in syslog.conf takes precedence.\" \/>\n<question id=\"\" type=\"tf\" text=\"The last matching component for rules in syslog.conf takes precedence.\" \/>\n<question id=\"\" type=\"tf\" text=\"The first matching component for rules in syslog.conf takes precedence.\" \/>\n<p>\nNote that multiple selectors on a single line can cause some confusion when\nthere are conflicting components within a selector. The thing to keep in mind\nis that the last component takes precedence. In the previous example, we\nspecified warning messages for all facilities and then “overwrote” portions\nof that for the mail, lpr and uucp facilities.\n<\/p>\n<question id=\"\" type=\"\" text=\"You will always find some system messages in the \/var\/log\/messages file.\" \/>\n<concept id=\"\" description=\"The system message file \/var\/log\/messages is simply a convention and system messages can be sent to any file, in any directory.\" \/>\n<p>\nMost system are configured by default to send a number of system messages <file type=\"\">\/var\/log\/messages<\/file>. This is commonly referered to as the “system messages file” or simple the “message file”. There is nothing holy about this file and is simply a convention. It is entirely possible to configure system logging to write to a different file or even different directory.\n<\/p>\n<task name=\"Rotate_logs_daily\">Create a Logrotate job to rotate a log file daily<\/task>\n<p><strong>Software Requirements:<\/strong><\/p>\n<p>\n<\/p>\n<p><strong>Configuration Requirements:<\/strong><\/p>\n<p>\n<\/p>\n<p><p><strong>Prerequisites:<\/strong><\/p>\n<p>\n<li>Edit files using ‘vi’.\n<\/p>\n<p><strong>Skills Taught:<\/strong><\/p>\n<p>\nAbility to create Logrotate-entries.\n<\/p>\n<task name=\"Rotate_logs_daily\">Create a Logrotate job to rotate a log file when it reaches 100 MB<\/task>\n<p><strong>Software Requirements:<\/strong><\/p>\n<p>\n<\/p>\n<p><strong>Configuration Requirements:<\/strong><\/p>\n<p>\n<\/p>\n<p><p><strong>Prerequisites:<\/strong><\/p>\n<p>\n<li>Edit files using ‘vi’.\n<\/p>\n<p><strong>Skills Taught:<\/strong><\/p>\n<p>\nAbility to create Logrotate-entries based on the size of the log file.\n<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Syslogd The workhorse of the Linux logging system is the system logging daemon or syslogd. This daemon is normally started from the system start-up (rc) scripts when the system goes into run level 1. Once running, almost any part of … <a href=\"http:\/\/www.linux-tutorial.info\/?page_id=221\">Continue reading <span class=\"meta-nav\">→<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-221","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/221","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=221"}],"version-history":[{"count":1,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/221\/revisions"}],"predecessor-version":[{"id":719,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/221\/revisions\/719"}],"wp:attachment":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=221"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}