ngIRCd logs to syslog, but only if there is a logger running. If you add 'use logger' to the init script's depend(), then it will spin up the logger before starting (if a logger is installed). You probably also want to add --with-syslog to myeconfargs (possibly bound to a syslog USE flag (which you'd have to add to IUSE). [1]: http://ngircd.barton.de/doc/INSTALL Reproducible: Always Steps to Reproduce: 1. rc-service syslog-ng stop 2. rc-service ngircd stop 3. rc default Actual Results: * Starting ngIRCd ... [ ok ] * Checking your configfile (/etc/syslog-ng/syslog-ng.conf) ... [ ok ] * Starting syslog-ng ... [ ok ] Expected Results: * Checking your configfile (/etc/syslog-ng/syslog-ng.conf) ... [ ok ] * Starting syslog-ng ... [ ok ] * Starting syslog-ng ... [ ok ] * Starting ngIRCd ... [ ok ]
Created attachment 371446 [details, diff] Patch adding syslog USE flag and 'use logger' clause
Created attachment 421926 [details, diff] Patch with the 'use logger' clause and updated copyright I would just add the 'use logger' to the initscript, as ngircd automatically finds the available syslog during configure. Any thoughts on that? Attached you may find the patch for the initscript, with the logger clause and copyright update.
(In reply to Moritz Kick from comment #2) > I would just add the 'use logger' to the initscript, as ngircd automatically > finds the available syslog during configure. It can't find it if there is no system logger installed ;). The syslog USE flag I added makes sure that syslog is installed and ngIRCd uses it if the USE flag is set, and that ngIRCd does not use syslog (even if it happens to be installed) if -syslog is set.
(In reply to W. Trevor King from comment #3) > (In reply to Moritz Kick from comment #2) > > I would just add the 'use logger' to the initscript, as ngircd automatically > > finds the available syslog during configure. > > It can't find it if there is no system logger installed ;). The syslog USE > flag I added makes sure that syslog is installed and ngIRCd uses it if the > USE flag is set, and that ngIRCd does not use syslog (even if it happens to > be installed) if -syslog is set. If we'd add the useflag we should probably enforce it by setting +syslog in IUSE, so we don't break expected behaviour. Also I'm quite unsure about depending on virtual/logger. But let me clear this up with some devs first :)
(In reply to Moritz Kick from comment #4) > If we'd add the useflag we should probably enforce it by setting +syslog in > IUSE, so we don't break expected behaviour. Defaulting to enabled is fine with me. And we may need an entry about this in metadata.xml, although I'm not sure that's required for USE flags defined in profiles/use.desc (like ‘syslog’ is). > Also I'm quite unsure about depending on virtual/logger. $ git grep 'syslog.*virtual/logger' turns up a number of other folks doing the same thing. What are you concerned about?
Created attachment 421930 [details] Updated initscript Just discussed this with some devs. The useflag isn't really needed as the configure script checks for syslog.h which is part of POSIX, so --with-syslog will be set in almost every case. The behaviour of the logging can also be controlled in the config file and the service can be started so it logs to console, so if you really would want ngircd to run without logging to syslog you could. Therefore the useflag would be kind of useless and the dependency on virtual/logger would just make it pull in unnecessary packages. The only thing I'd do is add 'use logger' to the initscript, so to make sure the syslog daemon is started if ngircd is run. Attached is the new initscript.
(In reply to Moritz Kick from comment #6) > The useflag isn't really needed as the configure script checks for syslog.h > which is part of POSIX, so --with-syslog will be set in almost every case. Part of having USE flags is that you can *disable* optional features. For example, maybe I'm building ngIRCd locally (where I have a system logger), but want to install it on a system where I don't have a system logger. With my patch, you can use USE=-syslog to compile an ngIRCd that doesn't include system logging code. > The behaviour of the logging can also be controlled in the config file and > the service can be started so it logs to console, so if you really would > want ngircd to run without logging to syslog you could. I haven't checked to see if ngIRCd compiled on a syslog-containing system actually runs on a syslog-less system. I'd expect you'd get linking errors at runtime, regardless of how you configured it. I'll test this tonight and report back. > Therefore the useflag would be kind of useless and the dependency on > virtual/logger would just make it pull in unnecessary packages. If you have already have system logger installed, virtual/logger will be a very lightweight dependency ;). And I expect folks will configure their syslog USE flag to match whether they want a logger installed or not.
(In reply to W. Trevor King from comment #7) > (In reply to Moritz Kick from comment #6) > > The behaviour of the logging can also be controlled in the config file and > > the service can be started so it logs to console, so if you really would > > want ngircd to run without logging to syslog you could. > > I haven't checked to see if ngIRCd compiled on a syslog-containing system > actually runs on a syslog-less system. I'd expect you'd get linking errors > at runtime, regardless of how you configured it. I'll test this tonight and > report back. Any update on that? I'd like this to be committed to the tree soon, so that this bug can finally be resolved.
(In reply to Moritz Kick from comment #8) > (In reply to W. Trevor King from comment #7) > > I haven't checked to see if ngIRCd compiled on a syslog-containing system > > actually runs on a syslog-less system. I'd expect you'd get linking errors > > at runtime, regardless of how you configured it. I'll test this tonight and > > report back. > > Any update on that? I'd like this to be committed to the tree soon, so that > this bug can finally be resolved. Oops, thanks for the ping. I haven't run a test, but lddtree doesn't list any syslog-specific libraries so I expect this wouldn't be a problem: $ lddtree $(command -v ngircd) /usr/sbin/ngircd (interpreter => /lib64/ld-linux-x86-64.so.2) libpam.so.0 => /lib64/libpam.so.0 libdl.so.2 => /lib64/libdl.so.2 libwrap.so.0 => /lib64/libwrap.so.0 libgnutls.so.28 => /usr/lib64/libgnutls.so.28 libtasn1.so.6 => /usr/lib64/libtasn1.so.6 libnettle.so.4 => /usr/lib64/libnettle.so.4 libhogweed.so.2 => /usr/lib64/libhogweed.so.2 libgmp.so.10 => /usr/lib64/libgmp.so.10 libz.so.1 => /lib64/libz.so.1 libc.so.6 => /lib64/libc.so.6 And the include file (so presumably also the “write to /dev/log” part of the implementation) are from glibc: $ equery belongs /usr/include/syslog.h * Searching for /usr/include/syslog.h ... sys-libs/glibc-2.20-r2 (/usr/include/syslog.h) The only remaining issue I can think of is binary packaging, where you want the USE flags to map unambiguously to the packaged binaries. But that's a narrow enough edge case on Gentoo that I'll live if you don't want to land your patch without the syslog USE flag.
(In reply to W. Trevor King from comment #9) > (In reply to Moritz Kick from comment #8) > > (In reply to W. Trevor King from comment #7) > > > I haven't checked to see if ngIRCd compiled on a syslog-containing system > > > actually runs on a syslog-less system. I'd expect you'd get linking errors > > > at runtime, regardless of how you configured it. I'll test this tonight and > > > report back. > > > > Any update on that? I'd like this to be committed to the tree soon, so that > > this bug can finally be resolved. > > Oops, thanks for the ping. I haven't run a test, but lddtree doesn't list > any syslog-specific libraries so I expect this wouldn't be a problem: > > $ lddtree $(command -v ngircd) > /usr/sbin/ngircd (interpreter => /lib64/ld-linux-x86-64.so.2) > libpam.so.0 => /lib64/libpam.so.0 > libdl.so.2 => /lib64/libdl.so.2 > libwrap.so.0 => /lib64/libwrap.so.0 > libgnutls.so.28 => /usr/lib64/libgnutls.so.28 > libtasn1.so.6 => /usr/lib64/libtasn1.so.6 > libnettle.so.4 => /usr/lib64/libnettle.so.4 > libhogweed.so.2 => /usr/lib64/libhogweed.so.2 > libgmp.so.10 => /usr/lib64/libgmp.so.10 > libz.so.1 => /lib64/libz.so.1 > libc.so.6 => /lib64/libc.so.6 > > And the include file (so presumably also the “write to /dev/log” part of the > implementation) are from glibc: > > $ equery belongs /usr/include/syslog.h > * Searching for /usr/include/syslog.h ... > sys-libs/glibc-2.20-r2 (/usr/include/syslog.h) > > The only remaining issue I can think of is binary packaging, where you want > the USE flags to map unambiguously to the packaged binaries. But that's a > narrow enough edge case on Gentoo that I'll live if you don't want to land > your patch without the syslog USE flag. Yeah but I guess if you binary package it for a target running a non POSIX compliant libc, you're going to experience worse problems than a non-working syslog :)
Created attachment 422848 [details, diff] Patch fixing this bug.
This ought be revbumped. I have adjusted this accordingly to cater to revbumping if only to get this finalised. copied ngircd.init.d to ngircd.init-r1.d edited the ngircd-23-r1.ebuild in install the corresponding ngircd.init-r1.d file. files/ngircd.init.d need remain while ngircd-20.3 is present as the only stabled version in portage. Note also it is stabled only x86 while the ngircd-23-r1.ebuild has KEYWORDS="~amd64 ~x86 ~x64-macos" By rights ngircd-23.ebuild should now be deleted and the freshly revbumped ngircd-23-r1.ebuild be made stable asap. commit 8de337a25216642f5667691c8b9a0128adbdcd4c Author: Ian Delaney <idella4@gentoo.org> Date: Fri Jan 15 12:13:35 2016 +0800 net-irc/ngircd: revbump to vn. 23-r1 with corresponding updated init script init script is files/ngircd.init-r1.d, ngircd-23-r1.ebuild edited to match, script adds use logger to depend(), patch by maintainer via the gentoo bug Gentoo bug: #503074 before closing the bug, I suggest you make a bug requesting purging of the ngircd-23.ebuild
