Bug#886731: linux-image-4.9.0-4-amd64: DKMS sends system in suspend since linux-image-4.9.0-3-amd64
Problem not solved. Running my laptop with unsecure old kernel. Any suggestions? Marc. ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
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
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
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.) ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
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. ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
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 ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
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 ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#890509: dh_installsystemd/init-system-helpers: support user units
Package: debhelper,init-system-helpers Severity: wishlist Hi there! I'm working on some GNOME changes (upstream) to support activating session components using systemd user units instead of execing them from gnome-session. As a part of this, a few packages will grow systemd user units. AFAICS dh_installsystemd and deb-systemd-helper don't support user units, only system ones. Particularly enabling/disabling is interesting - I think it'd be useful if they were to gain this functionality so that packagers don't have to manage the symlinks themselves. It's mostly a matter of additionally operating on the systemwide non-transient …/user directories listed in systemd.unit(5) - /etc/systemd/user and /usr/lib/systemd/user. I'll try to get some time to work on this change, but I wanted to get your opinions first. (If we decide this is indeed desirable, I'll clone/reassign the bug to each package.) I suppose from dh_installsystemd this should be done at a compat bump, to not break packages which might set user units up themselves already. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
