Comment # 50 on bug 1165351 from
(In reply to Luis Chamberlain from comment #49)
> (In reply to Luis Chamberlain from comment #48)
> > Note: I have a work around for now thanks to Anthony Iliopoulos, his
> > suggestion was to disable systemd from pam:
> > 
> > --- /etc/pam.d/common-session-pc.old	2020-03-25 13:42:38.404526416 +0100
> > +++ /etc/pam.d/common-session-pc	2020-03-25 13:42:47.308353223 +0100
> > @@ -28,7 +28,7 @@
> >  # at the start and end of sessions of *any* kind (both interactive and
> >  # non-interactive
> >  #
> > -session	optional	pam_systemd.so  debug
> > +#session	optional	pam_systemd.so  debug
> >  session	required	pam_limits.so	
> >  session	required	pam_unix.so	try_first_pass 
> >  session	optional	pam_umask.so
> > 
> > I'll also note that this issue is *still* present if you don't do the above,
> > but just disable NIS. I disabled NIS by commenting out /etc/yp.conf and
> > stopping ypserv.service and then disabling it. The only effective way to
> > work around this is disabling pam_Systemd.so from pam from commom-session-pc
> > as noted above.
> > 
> > But without a system to reproduce, we have no way of debugging it further. 
> > 
> > Thomas, I'll leave chivo with the pam_systemd.so enabled, but I'll disable
> > it on tuctuc. I'll keep using tuctuc for development, feel free to use chivo
> > for any further testing / debugging.
> 
> Odd, so no, I'm now able to reproduce with pam_systemd.so disabled but
> ypbind.service enabled. The only way to really work around this is to
> disable pam_systemd.so from /etc/pam.d/common-session-pc as noted earlier
> but also running:
> 
> systemctl stop ypbind.service
> systemctl disable ypbind.service

I confirm again: disabling ypbind.service but leaving pam_systemd.so enabled
still triggers this on chivo. I am leaving the system there with 2G of ram set
upon boot.


You are receiving this mail because: