Bug 11294 - [patch] logger(1) direct logging to other hosts
Summary: [patch] logger(1) direct logging to other hosts
Status: Closed Feedback Timeout
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 3.1-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 1999-04-23 18:10 UTC by Mikhail T.
Modified: 2018-11-06 14:08 UTC (History)
2 users (show)

See Also:


Attachments
file.diff (5.71 KB, patch)
1999-04-23 18:10 UTC, Mikhail T.
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail T. 1999-04-23 18:10:01 UTC
	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
	feature:

		logger -h logserver "This is a test"

Fix: This patches are against the latest -stable:
Comment 1 Marc.Perisa 2003-07-07 18:28:23 UTC
Hi,

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?

Marc
Comment 2 Mikhail Teterin 2003-07-07 18:42:04 UTC
=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
...") :-\

	-mi
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2011-10-04 19:30:15 UTC
State Changed
From-To: open->closed

proposed change already committed; feedback timeout
Comment 4 Mikhail T. 2011-10-04 19:41:58 UTC
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...

    -mi
Comment 5 Eitan Adler freebsd_committer freebsd_triage 2011-10-06 23:22:18 UTC
State Changed
From-To: closed->open

After a more careful reading I agree with mi
Comment 6 Eugene Grosbein freebsd_committer freebsd_triage 2017-08-09 17:50:42 UTC
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.
Comment 7 Mikhail T. 2017-08-09 17:58:47 UTC
(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?..
Comment 8 Eugene Grosbein freebsd_committer freebsd_triage 2017-08-09 18:55:05 UTC
(In reply to Mikhail T. from comment #7)

Sorry, misses that indeed. Would you like to re-format your patch for modern code base?
Comment 9 Mikhail T. 2017-08-09 19:28:03 UTC
(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!