With the default system installation including persistent journald by default, it doesn't seem useful anymore to have such dependencies. They
are leftovers from an era where not having a system logging setup that
just worked by default was a thing, and fortunately we are long past
that today.
TL;DR: drop or downgrade dependency on system-log-daemon from any
package that declares it
The list of affected packages according to apt-cache showpkg is not
that long either:
anacron
approx
fail2ban
fwlogwatch
heartbeat
hippotat-server
inetutils-ftpd
inetutils-inetd
inetutils-talkd
inetutils-telnetd
ldirectord
logcheck
lyskom-server
prelude-lml
psad
request-tracker4
request-tracker5
rlinetd
snort
socklog-run
socklog-run:i386
spamd
sympa
xinetd
xwatch
zoneminder
Hi,
On 5/27/24 11:29, Luca Boccassi wrote:
With the default system installation including persistent journald by default, it doesn't seem useful anymore to have such dependencies. They
are leftovers from an era where not having a system logging setup that
just worked by default was a thing, and fortunately we are long past
that today.
There is no need to advertise for the default setting. :)
For the benefit of Devuan, we could change this to "systemd-sysv | system-log-daemon".
The only breakage resulting from this change would be Debian based
container images that pull in a (nonfunctional, because not entrypoint) systemd instead of the logging daemon they expect, but that also breaks
when we demote the dependency, so that's not worse.
And anyone using a different entrypoint is unsupported by Debian anyway.
This MBF is
not about removing the virtual provides where they are defined, they
can stay as-is, but downgrading/removing the hard dependencies so that
we can make Debian minimal images.
In Bookworm we enabled persistent journald by default, which was the
right choice. The problem is that some packages declare a dependency on
the virtual package system-log-daemon, which we cannot add on systemd
given it would make rsyslog and other packages that also declare it uninstallable, which is not nice.
The list of affected packages according to apt-cache showpkg is not
that long either:
anacron
approx
fail2ban
fwlogwatch
heartbeat
hippotat-server
inetutils-ftpd
inetutils-inetd
inetutils-talkd
inetutils-telnetd
ldirectord
logcheck
lyskom-server
prelude-lml
psad
request-tracker4
request-tracker5
rlinetd
snort
socklog-run
socklog-run:i386
spamd
sympa
xinetd
xwatch
zoneminder
Hi,
On 5/27/24 19:59, Luca Boccassi wrote:
This MBF is
not about removing the virtual provides where they are defined, they
can stay as-is, but downgrading/removing the hard dependencies so that
we can make Debian minimal images.
So the policy becomes "a logging service is present even if not
explicitly declared." -- that sounds kind of like an Essential package, except that the interface is injected externally, and not visible in the package namespace.
My train of thought here is that there should be a "syslogd-is-journald" package that Provides/Conflicts system-log-daemon, so I can explicitly
select this during container image creation with the existing package selection mechanism -- basically if I build a container image with syslogd-is-journald, then it becomes my responsibility to fulfill that promise, just as it is my responsibility to start rsyslog from my
entrypoint when I build with rsyslog.
We cannot really avoid a regression for container builders here: the
implicit dependency on (effectively) rsyslog will go away, and if their entrypoint starts it explicitly (because no one uses sysvinit in a
container) without having it listed in the package list, that is broken anyway.
From systemd's immutable system images point of view, I think at least systemd must be installed into the immutable image anyway (for the
default units in /usr/lib to be defined), and systemd-sysv on top of
that doesn't use much space -- hence the idea to use systemd-sysv
instead of a new empty package as the alternative.
On Mon, 27 May 2024 at 03:29:53 +0100, Luca Boccassi wrote:
The list of affected packages according to apt-cache showpkg is not
that long either:
anacron
approx
fail2ban
fwlogwatch
heartbeat
hippotat-server
inetutils-ftpd
inetutils-inetd
inetutils-talkd
inetutils-telnetd
ldirectord
logcheck
lyskom-server
prelude-lml
psad
request-tracker4
request-tracker5
rlinetd
snort
socklog-run
socklog-run:i386
spamd
sympa
xinetd
xwatch
zoneminder
I think we can divide these into: packages that want to write to a logging service via the syslog protocol, and packages that want to read a
traditional plain-text syslog file.
For packages that want to write out messages via syslog(3) or equivalent
and have them get written out somewhere that the sysadmin can see them,
I agree that the systemd Journal (whether persistent or volatile) is sufficient to provide a suitable log sink. Obviously many sysadmins will
want these messages to persist across a reboot, but that's a configuration choice, for which I think defaulting to persistent but allowing volatile
at the sysadmin's own risk is a good arrangement.
However, for packages that want to read a traditional /var/log/syslog
or similar, notably logcheck, I think it might still make sense to declare
a dependency on system-log-daemon - this is not functionality that the systemd Journal provides. Obviously the same information exists and can
be retrieved by journalctl(1) or via libsystemd, or received and written
out to the traditional flat file over time by rsyslog or equivalent,
but it's no longer provided as a flat file on disk by default.
Yes this sounds reasonable - do you already have an idea about which
is which, from the list above?
From my limited knowledge of what they do, I would guess that approx, hippotat, inetutils-*d, request-tracker*, *inetd and spamd are just logsources that need a syslog-compatible logging sink, for which either
My train of thought here is that there should be a "syslogd-is-journald" package that Provides/Conflicts system-log-daemon...
hence the idea to use systemd-sysv instead of a new empty
package as the alternative
On Mon, 27 May 2024 at 14:38:44 +0100, Luca Boccassi wrote:
Yes this sounds reasonable - do you already have an idea about which
is which, from the list above?
Nothing reliable, so please check before opening bugs.
I know fail2ban and logcheck do read plain-text logs (although as
mentioned, fail2ban already has native Journal-reading support too), and I would guess that fwlogwatch, snort and xwatch probably also read the logs.
From my limited knowledge of what they do, I would guess that approx, hippotat, inetutils-*d, request-tracker*, *inetd and spamd are just log sources that need a syslog-compatible logging sink, for which eitherjournald or a traditional syslogd should be equally valid.
The others, no idea.
I know fail2ban and logcheck do read plain-text logs (although as
mentioned, fail2ban already has native Journal-reading support too), and
I would guess that fwlogwatch, snort and xwatch probably also read the
logs.
On Mon, 27 May 2024 at 03:29:53 +0100, Luca Boccassi wrote:
The list of affected packages according to apt-cache showpkg is not
that long either:
logcheck
However, for packages that want to read a traditional /var/log/syslog
or similar, notably logcheck,
Simon McVittie <smcv@debian.org> writes:
I know fail2ban and logcheck do read plain-text logs (although as
mentioned, fail2ban already has native Journal-reading support too), and
I would guess that fwlogwatch, snort and xwatch probably also read the
logs.
logcheck also has native journal-reading support.
Note that its dependency is only Suggests. I have not checked if that's there for some other reason.
So I think your syslogd-is-journald could not be a Provides on the
existing systemd-sysv package, and would have to be a separate package.
I'm not sure that the benefit is worth it (and I see that Luca is sure
that the benefit *isn't* worth it).
Along similar lines, I have wondered about dbus-{system,session}-bus-is-external packages as non-default providers
of dbus-{system,session}-bus, for use in containers that arrange for a suitable socket to be bind-mounted in from outside, but I'm unsure how
much appetite there is for a proliferation of packages whose metadata
is larger than their content for purposes like these - especially if
they could accidentally get installed (possibly on real systems rather
than in containers) by users who have not actually made the documented arrangements, resulting in spurious bug reports and extra support burden.
On 5/27/24 22:18, Simon McVittie wrote:
So I think your syslogd-is-journald could not be a Provides on the
existing systemd-sysv package, and would have to be a separate package.
I'm not sure that the benefit is worth it (and I see that Luca is sure
that the benefit *isn't* worth it).
I agree -- that's why I suggested changing the dependency to
"systemd-sysv | system-log-daemon"
This does not require an extra package, leaves out the system-log-daemon on most systems, still leaves the option of co-installing a flat logging daemon parallel to journald, and the packages work out-of-the-box on derived non-systemd distributions, so we don't waste developer time on maintaining a fork just for this issue.
I know fail2ban and logcheck do read plain-text logs (although as
mentioned, fail2ban already has native Journal-reading support too), and I >would guess that fwlogwatch, snort and xwatch probably also read the logs.
Hi!
On Tue, 2024-05-28 at 10:57:13 +0900, Simon Richter wrote:
On 5/27/24 22:18, Simon McVittie wrote:
So I think your syslogd-is-journald could not be a Provides on the existing systemd-sysv package, and would have to be a separate package. I'm not sure that the benefit is worth it (and I see that Luca is sure that the benefit *isn't* worth it).
I agree -- that's why I suggested changing the dependency to
"systemd-sysv | system-log-daemon"
This does not require an extra package, leaves out the system-log-daemon on most systems, still leaves the option of co-installing a flat logging daemon
parallel to journald, and the packages work out-of-the-box on derived non-systemd distributions, so we don't waste developer time on maintaining a
fork just for this issue.
I also care about portability and non-default alternatives, so I
assume for packages I maintain I'll be going instead with:
"<real-syslogd> | system-log-daemon | systemd-sysv"
I don't think the original proposal is technically sound to represent
what is really going on with logging, but given its tone and how it
is being rushed (not even a day for discussion), it seems to me like
spending time thinking or proposing alternatives would be a waste of
time and energy.
Hi,
On 5/27/24 22:18, Simon McVittie wrote:
So I think your syslogd-is-journald could not be a Provides on the
existing systemd-sysv package, and would have to be a separate package.
I'm not sure that the benefit is worth it (and I see that Luca is sure
that the benefit *isn't* worth it).
I agree -- that's why I suggested changing the dependency to
"systemd-sysv | system-log-daemon"
This does not require an extra package, leaves out the system-log-daemon
on most systems, still leaves the option of co-installing a flat logging daemon parallel to journald, and the packages work out-of-the-box on
derived non-systemd distributions, so we don't waste developer time on maintaining a fork just for this issue.
Hi,
socklog-run is a syslog daemon, it has no dependency on
system-log-daemon
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 360 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 128:34:14 |
| Calls: | 7,686 |
| Files: | 12,828 |
| Messages: | 5,711,088 |