Currently, there is no easy way to have a working logging
functionality without syslogd running on the local machine.
Which may require some more resources on a machine sends
everything out to a log server anyway.
Also, a user may want to log something on another machine
without accessing the local /etc/syslog.conf
The patches below add two more calls to the syslog(3) family
and add the `-h' option to logger(1) to take advantage of the
logger -h logserver "This is a test"
Fix: This patches are against the latest -stable:
the propossed change to logger(1) was done in version 1.6 for 5-CURRENT.
It is not yet in 4-STABLE.
The calls for syslog(3) et al weren't updated.
Is it still needed to send log information to a remote host without
syslogd locally running?
=the propossed change to logger(1) was done in version 1.6 for
=5-CURRENT. It is not yet in 4-STABLE.
=The calls for syslog(3) et al weren't updated.
=Is it still needed to send log information to a remote host without
=syslogd locally running?
My reasoning was that since the functionality will be present in the
system anyway, it would be better to place it into a library, from where
it can be used by other programs. This would benefit systems running in
embedded installations, which would prefer not to run the whole syslog
of their own, as well as others...
Locking the functionality inside a utility, while seemingly trying to
keep the libc cleaner, will only encourage ugliness like system("logger
proposed change already committed; feedback timeout
Marc's question from 2003 made little sense -- the submitter's opinion on it
being desirable for libc to offer the functionality is not affected by
logger(1)'s cleanup, and I presumed the question to be rhetorical. Thus
"feedback timeout" resolution is incorrect, in my opinion.
Yes, I do believe, libc should offer a function to send syslog datagram directly
to a different host. And -- 12 years ago -- I submitted a patch, that does this...
After a more careful reading I agree with mi
logger(1) got "-h" option long time ago. An idea of implementing this in a library got no attention (read: patch) over 10 years. There is no point in keeping this PR open for another decade. If one has an implementation, please fill new PR for a library enhancement.
(In reply to Eugene Grosbein from comment #6)
> An idea of implementing this in a library got no attention (read: patch) over
> 10 years. There is no point in keeping this PR open for another decade. If
> one has an implementation, please fill new PR for a library enhancement.
What? My 18 year-old patch does modify libc/gen/syslog.c adding two new library functions: syslogh and vsyslogh -- including man-page additions documenting both.
The ticket's very first comment mentions this, as do some of the follow-up comments. How could you have missed that?..
(In reply to Mikhail T. from comment #7)
Sorry, misses that indeed. Would you like to re-format your patch for modern code base?
(In reply to Eugene Grosbein from comment #8)
> Would you like to re-format your patch for modern code base?
That would have to wait for a weekend... Meanwhile could you look at Bug #210537, where I have just done a similar refreshening? Thanks!