|
Bugzilla – Full Text Bug Listing |
| Summary: | systemd re-adds itself to pam-config with every update | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Stefan Seyfried <seife> |
| Component: | Basesystem | Assignee: | systemd maintainers <systemd-maintainers> |
| Status: | RESOLVED WONTFIX | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | bwiedemann, fbui, fcrozat |
| Version: | 13.2 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Stefan Seyfried
2014-12-08 10:33:12 UTC
Without ``systemd-pam'' the session control including session features does not work (like the /run/user/<uid>/ directory, the auto mountd below there, the permission control, nor any other job which *now* systemd-logind does). Read man 8 pam_systemd I'm not willingly to help system admins to shot them into their feets. But *if* I disabled it because after reading pam_systemd(8) and finding out it does nothing for me, then it should be kept disabled. Not reenabled on every package update. It's my system after all. BTW: the auto mount does not work at all on a server when I log in via ssh, and all the users running cron jobs also don't get any benefits from pam_systemd, but it really floods the logs with useless messages. I understand that people might want pam_systemd on desktops, but on servers? We had to "force" enabling pam-config -a --systemd in the past because the upgrade path was not working 100% of case and could cause some systems to not have pam_systemd added in their configuration, causing all sort of problems. And we obviously don't want that to happen again.. And thus we break all servers and all users who deliberately disabled this instead of fixing the broken update routine? (In reply to Stefan Seyfried from comment #5) > And thus we break all servers and all users who deliberately disabled this > instead of fixing the broken update routine? So far, you are the first one who are reporting this issue (unlike the issue which forced us to do the pam-config call) Do you have a suggestion on how to fix this without causing a regression ? My idea would be to only run the "pam-config -a --systemd" on installation, and not on update. There needs to be a way to know if it is "rpm -i" or "rpm -{U,F}" or %restart_on_update would not work.
OTOH, pam_systemd is mainly useful for desktop systems IIUC, so adding it in some central desktop package %post might be an option.
Another option would be to put pam_systemd into its own package, so that it can be uninstalled if not needed. $Desktop could then recommend it.
For "I'm the only one complaining": Lots of people are annoyed for example by having these 50 lines of log messages every minute for their cron job that collects system statistics. Those are paying customers with SLES12, so you won't find them on bugzilla, though. But they are not amused by this anyway.
Ok, it's only 35 additional lines of log messages for each cron job ;) (In reply to Stefan Seyfried from comment #7) > My idea would be to only run the "pam-config -a --systemd" on installation, > and not on update. There needs to be a way to know if it is "rpm -i" or "rpm > -{U,F}" or %restart_on_update would not work. which will break pre-systemd system upgrade (or system which were using systemd before pam_systemd was introduced). Not an option. > OTOH, pam_systemd is mainly useful for desktop systems IIUC, so adding it in > some central desktop package %post might be an option. Seat control is not a desktop only feature. > Another option would be to put pam_systemd into its own package, so that it > can be uninstalled if not needed. $Desktop could then recommend it. > > For "I'm the only one complaining": Lots of people are annoyed for example > by having these 50 lines of log messages every minute for their cron job > that collects system statistics. Those are paying customers with SLES12, so > you won't find them on bugzilla, though. But they are not amused by this > anyway. They need to open a service request about this, then (and this bug is about openSUSE, not SLE btw) (In reply to Frederic Crozat from comment #9) > Seat control is not a desktop only feature. But it is "obscure" on non-desktop systems, to say the least. > They need to open a service request about this, then (and this bug is about > openSUSE, not SLE btw) They will, once they dare to even try to use SLE12 (their desier to do so is certainly not helped by "features" like this one ;) Anyway. I'll work around this bug in the build service for my own usage, trying to make systemd usable out of the box is just too much effort for me. 13.2 has reached EOL and is not supported anymore. Feel free to open a new bug report if this still can be reproduced on a newer/supported distro such as Leap or Tumbleweed. Thanks. |