Bug#717388: Volunteers needed to work on enabling persistent journal
Am Do., 15. Feb. 2018 um 21:55 Uhr schrieb Andreas Henriksson : > not great about this. Feels like overengineering. I think we > might need something much "simpler" in the hope that if we invent less > we'll get less stuff wrong. It should also help when we try to sell > our solution to the systemd maintainers (and the general Debian > community). Just a clarification: Buster will ship without persistent journal? Something OpenSUSE and RH have been using for years without real problems? Best Martin
Bug#717388: Volunteers needed to work on enabling persistent journal
On Thu, Feb 15, 2018 at 09:55:42PM +0100, Andreas Henriksson wrote: > On Thu, Feb 15, 2018 at 09:31:28AM -0800, Josh Triplett wrote: > > systemd-journal-syslog Depends on systemd-journal-persistent | > > systemd-journal-transient (so that you *can* still explicitly choose to > > have syslog with transient-only storage, useful for some systems such as > > those with no persistent storage at all) and Conflicts/Provides > > system-log-daemon. > > AIUI I don't see the point here. Once you Provides system-log-daemon > you can't have any other system-log-daemon installed (as they conflict > against your provides). The point there is that you then have a provider of system-log-daemon that acts as a proper syslog implementation but only logs in-memory. That's useful for some embedded systems, for instance. - Josh Triplett
Bug#717388: Volunteers needed to work on enabling persistent journal
On Thu, Feb 15, 2018 at 09:31:28AM -0800, Josh Triplett wrote:
> How about this:
>
> systemd-journal-transient ships
> /usr/lib/systemd/journald.conf.d/transient.conf which explcitly disables
> the persistent jorunal by setting Storage=volatile.
>
> systemd-journal-persistent ships
> /usr/lib/systemd/journald.conf.d/persistent.conf which explicitly
> enables the persistent journal by setting Storage=persistent.
Basically inventing a package for a config setting.
Other packages will easily be fooled by this. It's easy to assume
you can just then depend on eg. systemd-journal-persistent and
assume there's actually persistent journal but the admin might
have a setting in /etc/systemd/journald.conf that overrides
the systemd-journal-{transient,persistent} setting.
Maybe it's impossible to satisfy everyone, but my gut feeling is
not great about this. Feels like overengineering. I think we
might need something much "simpler" in the hope that if we invent less
we'll get less stuff wrong. It should also help when we try to sell
our solution to the systemd maintainers (and the general Debian
community).
>
> systemd-journal-syslog Depends on systemd-journal-persistent |
> systemd-journal-transient (so that you *can* still explicitly choose to
> have syslog with transient-only storage, useful for some systems such as
> those with no persistent storage at all) and Conflicts/Provides
> system-log-daemon.
AIUI I don't see the point here. Once you Provides system-log-daemon
you can't have any other system-log-daemon installed (as they conflict
against your provides).
>
> default-system-log-daemon would depend on rsyslog for now, and in the
> future, it could start depending on systemd-journal-syslog instead. (Or
> we could handle it as a virtual package, though that could make upgrades
> harder.)
Regards,
Andreas Henriksson
Bug#717388: Volunteers needed to work on enabling persistent journal
On Thu, Feb 15, 2018 at 06:16:20PM +0100, Andreas Henriksson wrote: > On Thu, Feb 15, 2018 at 09:07:21AM -0800, Josh Triplett wrote: > > On Thu, Feb 15, 2018 at 05:14:03PM +0100, Andreas Henriksson wrote: > [...] > > > - (How to handle updates? Consensus seemed to be towards no change on > > >updates.) > > > > I'm interested in helping with this. > > > > I think we should *always* provide /var/log/journal, and continue to > > configure systemd to not use the persistent journal by default rather > > than autodetecting via the existence of /var/log/journal; that way, we > [...] > > Interesting proposal, but how do we handle upgrades in this case? > > I'm thinking about the (possibly small) group of people who has > manually uninstalled (r)syslog and created the directory according > to /usr/share/doc/systemd/README.Debian.gz instructions (and rely on > autodetection). Maybe a NEWS.Debian entry is enough to tell them > they now need to install the package that enables persistant journal, > but at the same time there will be those who do not pay enough attention > and ends up with no logging what so ever after an upgrade which makes > me a bit worried How about this: systemd-journal-transient ships /usr/lib/systemd/journald.conf.d/transient.conf which explcitly disables the persistent jorunal by setting Storage=volatile. systemd-journal-persistent ships /usr/lib/systemd/journald.conf.d/persistent.conf which explicitly enables the persistent journal by setting Storage=persistent. systemd-journal-syslog Depends on systemd-journal-persistent | systemd-journal-transient (so that you *can* still explicitly choose to have syslog with transient-only storage, useful for some systems such as those with no persistent storage at all) and Conflicts/Provides system-log-daemon. default-system-log-daemon would depend on rsyslog for now, and in the future, it could start depending on systemd-journal-syslog instead. (Or we could handle it as a virtual package, though that could make upgrades harder.)
Bug#717388: Volunteers needed to work on enabling persistent journal
On Thu, Feb 15, 2018 at 05:14:03PM +0100, Andreas Henriksson wrote: > Mostly for the record... > > I asked Michael Biebl about this bug report and if it's time to > reconsider it for Buster. He mentioned it probably should and that he > now sees the journal as being mature and robust enough, but that he does > not have time to work on it. The same likely goes for the rest of the > Debian systemd maintainers team as well. The main blocker is now thus > getting the job done. > > There where some discussion on irc following this that I'll try to > summarize, mostly paraphrasing: > > The main issue is making sure there's consensus on the change. > > Implementation wise: > - we should make sure to not store logs twice, so (r)syslog daemon > should not be part of the default install once this is done. > - should /var/log/journal be created by a separate package or not? > - Should the package creating /var/log/journal have Provides: > system-log-daemon, kernel-log-daemon ? > That would make a syslog daemon uninstallable, as all of them > Conflict/Provides/Replaces system-log-daemon. > Not adding the provides was suggested, but then the rdeps of > system-log-daemon (primarily anacron which is part of default install) > would pull in a system log daemon and we would have double logging. > The discussion was leaning towards all rdeps needing fixing. > - (How to handle updates? Consensus seemed to be towards no change on >updates.) I'm interested in helping with this. I think we should *always* provide /var/log/journal, and continue to configure systemd to not use the persistent journal by default rather than autodetecting via the existence of /var/log/journal; that way, we don't have issues with packages accidentally enabling the journal just because they want that directory for other reasons, such as systemd-journal-remote. Then, let's have an installable package that enables the journal using a drop-in configuration snippet in /usr/lib/systemd/journald.conf.d/*.conf , and an additional installable package that Provides/Conflicts/Replaces system-log-daemon and depends on the package providing that drop-in configuration snippet. That way, people can use journald as their *only* syslog, *or* they can choose to enable both it and syslog if they want something like remote syslogging. Separately, we really need to move to a "default-system-log-daemon | system-log-daemon" approach for Depends/Recommends/Suggests from other packages, so that we can change the defaults more easily. And at that point, once we've made it trivial to switch between rsyslog and systemd-journal-syslog by just installing a different package, we could potentially switch the default to systemd-journal-syslog.
Bug#717388: Volunteers needed to work on enabling persistent journal
On Thu, Feb 15, 2018 at 09:07:21AM -0800, Josh Triplett wrote: > On Thu, Feb 15, 2018 at 05:14:03PM +0100, Andreas Henriksson wrote: [...] > > - (How to handle updates? Consensus seemed to be towards no change on > >updates.) > > I'm interested in helping with this. > > I think we should *always* provide /var/log/journal, and continue to > configure systemd to not use the persistent journal by default rather > than autodetecting via the existence of /var/log/journal; that way, we [...] Interesting proposal, but how do we handle upgrades in this case? I'm thinking about the (possibly small) group of people who has manually uninstalled (r)syslog and created the directory according to /usr/share/doc/systemd/README.Debian.gz instructions (and rely on autodetection). Maybe a NEWS.Debian entry is enough to tell them they now need to install the package that enables persistant journal, but at the same time there will be those who do not pay enough attention and ends up with no logging what so ever after an upgrade which makes me a bit worried Regards, Andreas Henriksson
Bug#717388: Volunteers needed to work on enabling persistent journal
Mostly for the record... I asked Michael Biebl about this bug report and if it's time to reconsider it for Buster. He mentioned it probably should and that he now sees the journal as being mature and robust enough, but that he does not have time to work on it. The same likely goes for the rest of the Debian systemd maintainers team as well. The main blocker is now thus getting the job done. There where some discussion on irc following this that I'll try to summarize, mostly paraphrasing: The main issue is making sure there's consensus on the change. Implementation wise: - we should make sure to not store logs twice, so (r)syslog daemon should not be part of the default install once this is done. - should /var/log/journal be created by a separate package or not? - Should the package creating /var/log/journal have Provides: system-log-daemon, kernel-log-daemon ? That would make a syslog daemon uninstallable, as all of them Conflict/Provides/Replaces system-log-daemon. Not adding the provides was suggested, but then the rdeps of system-log-daemon (primarily anacron which is part of default install) would pull in a system log daemon and we would have double logging. The discussion was leaning towards all rdeps needing fixing. - (How to handle updates? Consensus seemed to be towards no change on updates.) Are you interested in helping out making this happen? Speak up! (I'm interested to work on this myself, but my time is also quite limited so it might not happen for buster unless others also help out.) system-log-daemon rdeps: $ grep-dctrl -FDepends,Recommends system-log-daemon -sSource:Package < /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_binary-amd64_Packages | uniq Package: anacron Package: approx Package: cloudprint Package: fwlogwatch Package: heartbeat Source: inetutils Package: logcheck Source: ltsp Package: lyskom-server Package: nullmailer Package: prelude-lml Package: psad Package: request-tracker4 Source: resource-agents Package: rlinetd Package: snort Package: sympa Package: xinetd Package: zoneminder Regards, Andreas Henriksson
