Можно ли писать прямиком в syslog?
Спасибо за ваш ответ. А если такая проблема: я цепляю к своей программе библиотеку, которая внутри считывает переменную окружения(путь до файла) и пишет в него. Мне надо писать в syslog внутри библиотеки используется write(), переписывать библиотеку не вариант.
Обычно /dev/log это симлинк на srw-rw-rw- 1 root root 0 Oct 8 23:26 /run/systemd/journal/dev-log= . Команда file /run/systemd/journal/dev-log= сообщает, что на самом деле это сокет, а fuser вместе с ps покажут, что данный сокет слушает демон /lib/systemd/systemd-journald . Т.о. для записи сообщений вам нужно использовать, например, echo «. » | netcat -Uu /dev/log
2 ответа 2
Мне надо писать в syslog внутри библиотеки используется write()
Это кто Вас надоумил так делать?! 🙂 Два момента. Первый:
$ ls -l /var/log/sys* -rw-r----- 1 syslog adm 20148 окт 8 09:05 /var/log/syslog -rw-r----- 1 syslog adm 380325 окт 8 08:22 /var/log/syslog.1 -rw-r----- 1 syslog adm 46102 окт 7 08:25 /var/log/syslog.2.gz -rw-r----- 1 syslog adm 51345 окт 4 08:26 /var/log/syslog.3.gz -rw-r----- 1 syslog adm 212595 окт 3 08:47 /var/log/syslog.4.gz -rw-r----- 1 syslog adm 71915 окт 1 08:28 /var/log/syslog.5.gz -rw-r----- 1 syslog adm 54724 сен 30 08:23 /var/log/syslog.6.gz -rw-r----- 1 syslog adm 82350 сен 27 08:29 /var/log/syslog.7.gz Понимаете, что это означает? То, что писать в этот файл может только демон syslog, а читать — только он и члены группы adm. Так что, записать с помощью write() у Вас не получится никак. Без прав root.
Второе. Для того, что бы пользоваться услугами демона syslog существует набор стандартных системных функций:
void openlog(const char *ident, int option, int facility); void syslog(int priority, const char *format, . ); void closelog(void); А тех программистов, которые пишут свои собственные «лог-файлы» с использованием write() я считаю не очень уными людьми. Ведь достаточно просто выполнить команду
и можно посмотреть готовое решение проблемы. Особенно не люблю программёров, которые сообщения об ошибках и отладочные сообщения выдают с помощью printf(). Когда в службу поддержки обращается клиент и говорит, что у него ВЧЕРА было что-то непонятное с программой, то эти сообщения в ЕГО stderr исчезнувшие ещё вчера — представляют просто таки «бесценную» помощь для программиста сопровождения.
На самый крайний случай, если заменить write() на syslog() нет никакой возможности, рекомендую попробовать такой метод:
- С помощью inotify (man 7 inotify) устанавливает слежение за файлом, в который исходная программа пишет сообщения.
- Получив уведомление о записи в этот файл, программа считывает добавленный кусок текста. Это можно сделать, зная исходную и новую длину файла.
- Записывает полученный текст в системный лог, используя syslog().
Redirecting bash script output to syslog
That’s right, a post about logging from bash scripts. Cool as fuck.
Anyway, this was prompted by the following tweet:
I could see roughly what was going on here, but I didn’t quite understand how it worked. In particular, what on earth was the 1> >(logger . ) bit all about?
What does it do?
Adding this line to the top of your bash script will cause anything printed on stdout and stderr to be sent to the syslog 1 , as well as being echoed back to the original shell’s stderr.
It’s certainly desirable to have your script output sent to a predictable location, so how does this work?
Deconstructing the command
exec 1> >(logger -s -t $(basename $0)) 2>&1
exec is a bash builtin, so to see what it does, we run help exec :
exec: exec [-cl] [-a name] [command [args . ]] [redirection . ] Replace the shell with the given command. Execute COMMAND, replacing this shell with the specified program. ARGUMENTS become the arguments to COMMAND. If COMMAND is not specified, any redirections take effect in the current shell.
In this case exec is being used without COMMAND – this line is redirecting I/O for the current shell. So what do the redirections do? To simplify things let’s clear out the nested commands and just look at the redirection:
This is pretty simple redirection, obscured by that charming and easily google-able bash syntax that we all know and love bluff and tolerate. There are two redirections, the first being:
This redirects file descriptor 1 (stdout) to the location >(some-command) . That’s not a normal filename, though: it’s a process substitution, which is a non-POSIX bash feature 2 . >(some-command) returns a file descriptor that some-command will use as its stdin. This is exactly the same as piping our script’s stdout into some-command .
Then we redirect file descriptor 2 (stderr) to the same location as file descriptor 1:
In summary, we’ve redirected both stdout and stderr for our script to the same place: the stdin for another process, which is a command running in the background. In effect, this is the same as running the script at the command line like so:
$ ./some-script 2>&1 | some-command
In this case, some-command is:
From the logger(1) manpage we can see that this writes entries to syslog, tagged ( -t ) with the filename of our script ( $(basename $0) ) and echoing them to standard error ( -s ).
So the full line takes both stdout and stderr from our script, and redirects them to the logger command, which sends them to the syslog and echoes them back to stderr.
Testing it out
Let’s write a very simple test script, logger_test :
#!/bin/bash exec 1> >(logger -s -t $(basename $0)) 2>&1 echo "writing to stdout" echo "writing to stderr" >&2
When we run this on a Ubuntu system we see the following:
$ ./logger_test logger_test: writing to stdout logger_test: writing to stderr
We can also inspect the syslog (you may need root privileges):
$ grep logger_test /var/log/syslog Sep 9 15:39:37 my-machine logger_test: writing to stdout Sep 9 15:39:37 my-machine logger_test: writing to stderr
Great! We’ve got our output in the syslog and in our own console. What’s the downside?
Mixed stderr and stdout
Because we’re redirecting both stdout and stderr to a logger process, and getting them back on stderr, we can no longer distinguish between normal and error output, either in the syslog or in our terminal.
We could address this by using two background processes:
#!/bin/bash exec 1> >(logger -s -t $(basename $0) 2>&1) exec 2> >(logger -s -t $(basename $0)) echo "writing to stdout" echo "writing to stderr" >&2
Here we send stdout to a separate logger process, but redirect that process’s stderr back to stdout. We can now distinguish between stderr and stdout in our terminal, but we run into a second problem…
Out-of-order messages
If we run our new script several times we are very likely to see the following:
$ ./logger_test logger_test: writing to stderr logger_test: writing to stdout
This is because two separate background processes are handling our stdout and stderr messages, and there’s no guarantee that they’ll write their output in order.
We’re caught: if we’re getting our terminal output from background processes, we can either use one background process, and receive ordered messages but lose the ability to distinguish stdout and stderr; or we can use separate background processes, and distinguish between stdout and stderr but lose guaranteed message ordering.
An alternative approach
Ideally we would like the following:
- log messages sent to syslog
- stdout and stderr kept separate
- stdout and stderr message order preserved
We’ve established that we can’t have all of this by simply redirecting our output to background processes. An alternative approach would be to use helper functions for logging:
#!/bin/bash readonly SCRIPT_NAME=$(basename $0) log() echo "$@" logger -p user.notice -t $SCRIPT_NAME "$@" > err() echo "$@" >&2 logger -p user.error -t $SCRIPT_NAME "$@" > log "writing to stdout" err "writing to stderr"
This way we get our normal terminal output via the shell’s own stdout and stderr, but we can still send messages to syslog and tag them with appropriate priorities (we can also fancy up our terminal output with timestamps and colours if we want to).
The downside is that we have to explicitly log everything we want sent to syslog. If we want the output of a command our script runs to be sent to syslog, then we have to capture that output and log it, too.
Conclusions
I’m not very good at these. Um…
- Centralised logging is good
- But so is separable and ordered output
- So use whatever approach is most appropriate for your task I guess?
- Per Wikipedia, Syslog is a standard for computer message logging. In practice, this means that on any Unix-like system there will be a daemon running that will accept syslog messages, storing them in a central repository. This makes it a useful place to go looking for information about system processes and other processes that aren’t necessarily important enough for dedicated log files. ↩
- The same effect could be achieved in a POSIX-compliant way using named pipes. ↩
syslog(3) — Linux man page
closelog() closes the descriptor being used to write to the system logger. The use of closelog() is optional.
openlog() opens a connection to the system logger for a program. The string pointed to by ident is prepended to every message, and is typically set to the program name. If ident is NULL, the program name is used. (POSIX.1-2008 does not specify the behavior when ident is NULL.)
The option argument specifies flags which control the operation of openlog() and subsequent calls to syslog(). The facility argument establishes a default to be used if none is specified in subsequent calls to syslog(). Values for option and facility are given below. The use of openlog() is optional; it will automatically be called by syslog() if necessary, in which case ident will default to NULL.
syslog() generates a log message, which will be distributed by syslogd(8). The priority argument is formed by ORing the facility and the level values (explained below). The remaining arguments are a format, as in printf(3) and any arguments required by the format, except that the two character sequence %m will be replaced by the error message string strerror(errno). A trailing newline may be added if needed.
The function vsyslog() performs the same task as syslog() with the difference that it takes a set of arguments which have been obtained using the stdarg(3) variable argument list macros.
The subsections below list the parameters used to set the values of option, facility, and priority.
option The option argument to openlog() is an OR of any of these: LOG_CONS
Write directly to system console if there is an error while sending to system logger.
Open the connection immediately (normally, the connection is opened when the first message is logged).
Don’t wait for child processes that may have been created while logging the message. (The GNU C library does not create a child process, so this option has no effect on Linux.)
The converse of LOG_NDELAY; opening of the connection is delayed until syslog() is called. (This is the default, and need not be specified.)
(Not in POSIX.1-2001 or POSIX.1-2008.) Print to stderr as well.
Include PID with each message.
facility The facility argument is used to specify what type of program is logging the message. This lets the configuration file specify that messages from different facilities will be handled differently. LOG_AUTH
security/authorization messages (private)
clock daemon (cron and at)
system daemons without separate facility value
kernel messages (these can’t be generated from user processes) LOG_LOCAL0 through LOG_LOCAL7
reserved for local use LOG_LPR
messages generated internally by syslogd(8) LOG_USER (default)
generic user-level messages LOG_UUCP
level This determines the importance of the message. The levels are, in order of decreasing importance: LOG_EMERG
action must be taken immediately
normal, but significant, condition
debug-level message The function setlogmask(3) can be used to restrict logging to specified levels only.
Conforming To
The functions openlog(), closelog(), and syslog() (but not vsyslog()) are specified in SUSv2, POSIX.1-2001, and POSIX.1-2008. POSIX.1-2001 specifies only the LOG_USER and LOG_LOCAL* values for facility. However, with the exception of LOG_AUTHPRIV and LOG_FTP, the other facility values appear on most UNIX systems. The LOG_PERROR value for option is not specified by POSIX.1-2001 or POSIX.1-2008, but is available in most versions of UNIX.
Notes
The argument ident in the call of openlog() is probably stored as-is. Thus, if the string it points to is changed, syslog() may start prepending the changed string, and if the string it points to ceases to exist, the results are undefined. Most portable is to use a string constant.
Never pass a string with user-supplied data as a format, use the following instead: