$ rpm -q apcupsd apcupsd-3.14.14-29.fc39.x86_64 We had a power outage at home and two of our Linux (Dell) desktops each experienced a difficult failure mode. The machines, both running the same version of apcupsd, both denied users from logging in after power was restored. The machines booted all the way to the login screens (window manager, or tty login) and after correctly entering username and passwords, "POWER FAILURE" appeared and the login attempts were terminated. Since we hadn't bothered to set up any root passwords, this meant we were locked out of these machines. I was able to recover them using a live fedora image and mounting the /root/ directory. The problem was resolved by deleting the /etc/nologin file that contained the message "POWER FAILURE". Subsequent boots then worked fine. A follow on power outage yielded exactly the same problem. Worked around in the same way. I've edited the /etc/apcupsd/apcupsd.conf file and replaced the NOLOGIN line to read: NOLOGIN=/tmp I've not yet had another power outage to confirm this works around the problem. Reproducible: Always Steps to Reproduce: 1. lose power and run down the APC UPS battery 2. wait for power to return 3. try to login Actual Results: Denied login with "POWER FAILURE" message. Expected Results: Login just works. I would have expected apcupsd would write this info to some /var/run/ file and it would be erased as some part of the regular boot sequence. My guess is that this module is what is denying login. $ strings /lib64/security/pam_nologin.so |grep nolo pam_nologin.so /var/run/nologin /etc/nologin pam_nologin.so-1.5.3-3.fc39.x86_64.debug Via all of these configurations: $ grep -n nologin /etc/pam.d/* /etc/pam.d/gdm-autologin:5:account required pam_nologin.so /etc/pam.d/gdm-fingerprint:4:account required pam_nologin.so /etc/pam.d/gdm-password:6:account required pam_nologin.so /etc/pam.d/gdm-smartcard:4:account required pam_nologin.so /etc/pam.d/login:4:account required pam_nologin.so /etc/pam.d/ppp:3:account required pam_nologin.so /etc/pam.d/remote:4:account required pam_nologin.so /etc/pam.d/sshd:5:account required pam_nologin.so /etc/pam.d/vmtoolsd:4:account required pam_nologin.so
[ FWIW This bug started out as a PS to https://bugzilla.redhat.com/show_bug.cgi?id=1047535 ]
Hello, have you already discussed this in the upstream apcupsd mailing list? http://www.apcupsd.org/wordpress/bug-reporting/ It would be usedul to understand if other distros are affected too
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
Hello, I cannot find any trace of /etc/nologin manipulation in apcupsd source code # dnf install ripgrep $ fedpkg clone apcupsd $ cd apcupsd $ fedpkg sources $ tar -xvzf apcupsd-3.14.14.tar.gz $ rg nologin Can you please manually trigger a power failure and check if you still experience this problem? Thank you
*** Bug 2259308 has been marked as a duplicate of this bug. ***
I don't have the ssh access needed to reproduce what was suggested in comment 4. Here are some pointers for an alternative strategy for digging into this issue with the sources. Based on three cursory greps, I'd say this is likely something coming out of the autoconf setup. $ wget https://kojipkgs.fedoraproject.org//packages/apcupsd/3.14.14/29.fc39/src/apcupsd-3.14.14-29.fc39.src.rpm $ rpm install ./apcupsd-3.14.14-29.fc39.src.rpm $ cd ~/rpmbuild/SOURCES $ tar zvfx apcupsd-3.14.14.tar.gz $ cd apcupsd-3.14.14 $ find . | xargs grep "POWER FAILURE" 2>/dev/null ./include/defines.h:#define POWERFAIL "POWER FAILURE\n" /* put in nologin file */ ./platforms/mingw/onbattery.vbs:MyEmailSubject = "POWER FAILURE at: " & MyLocation ./doc/apcupsd.conf.5:.Ss POWER FAILURE CONFIGURATION DIRECTIVES ./examples/hid-ups.c: printf("POWER FAILURE\n"); $ find . | xargs grep "POWERFAIL" 2>/dev/null ./include/defines.h:#define POWERFAIL "POWER FAILURE\n" /* put in nologin file */ ./include/struct.h: SMART_TEST_POWERFAIL, ./platforms/sun/apccontrol.in:POWERFAILDIR=@PWRFAILDIR@ ./platforms/sun/apcupsd.in:POWERFAILDIR=@PWRFAILDIR@ ./platforms/sun/apcupsd.in: rm -f ${POWERFAILDIR}/powerfail ./src/action.c: write(lgnfd, POWERFAIL, strlen(POWERFAIL)); $ find . | xargs grep "PWRFAILDIR" 2>/dev/null ./configure:PWRFAILDIR ./configure:# set the default PWRFAILDIR ./configure:PWRFAILDIR=${sysconfdir} ./configure: PWRFAILDIR=/var/run ./configure: PWRFAILDIR=/etc ./configure:# now allow user to specify PWRFAILDIR ./configure: withval=$with_pwrfail_dir; PWRFAILDIR="$withval"; ./configure:#define PWRFAILDIR "$PWRFAILDIR" ./configure: Power Fail dir ${PWRFAILDIR} ./platforms/debian/ups-monitor.in: if [ -f @PWRFAILDIR@/powerfail ]; then ./platforms/debian/apcupsd.in: rm -f @PWRFAILDIR@/powerfail ./platforms/gentoo/ebuild:XPWRFAILDIR=${XSYSCONFDIR} ./platforms/gentoo/ebuild: --with-pwrfail-dir=${XPWRFAILDIR} \ ./platforms/gentoo/halt.in:if [ -f @PWRFAILDIR@/powerfail ]; then ./platforms/sun/rc0.solaris.in:if [ -f @PWRFAILDIR@/powerfail ]; then ./platforms/sun/apccontrol.in:POWERFAILDIR=@PWRFAILDIR@ ./platforms/sun/apcupsd.in:POWERFAILDIR=@PWRFAILDIR@ ./platforms/etc/apcupsd.conf.in:# PWRFAILDIR <path to powerfail directory> ./platforms/etc/apcupsd.conf.in:PWRFAILDIR @PWRFAILDIR@ ./platforms/yellowdog/awkhaltprog.in: print "if [ -f @PWRFAILDIR@/powerfail ]; then # ***apcupsd***" ./platforms/yellowdog/apcupsd.in: rm -f @PWRFAILDIR@/powerfail ./platforms/yellowdog/apcupsd.spec.in: print "if [ -f @PWRFAILDIR@/powerfail ]; then # ***apcupsd***" ./platforms/yellowdog/apcupsd.spec.in: print " @PWRFAILDIR@/apccontrol killpower # ***apcupsd***" ./platforms/yellowdog/apcupsd.spec.in: print "if [ -f @PWRFAILDIR@/powerfail ]; then # ***apcupsd***" ./platforms/yellowdog/apcupsd.spec.in: print " @PWRFAILDIR@/apccontrol killpower # ***apcupsd***" ./platforms/freebsd/Makefile: echo "if [ -f $(PWRFAILDIR)/powerfail ]; then # TAG_APCUPSD";\ ./platforms/freebsd/apccontrol.in: if [ -f @PWRFAILDIR@/powerfail ] ; then ./platforms/freebsd/apcupsd.in: rm -f @PWRFAILDIR@/powerfail ./platforms/apccontrol.in: if [ -f @PWRFAILDIR@/powerfail ] ; then ./platforms/hpux/apcupsd.in: rm -f @PWRFAILDIR@/powerfail ./platforms/hpux/halt.in:if [ -f @PWRFAILDIR@/powerfail ]; then ./platforms/redhat/awkhaltprog.in: print "if [ -f @PWRFAILDIR@/powerfail ]; then # ***apcupsd***" ./platforms/redhat/apcupsd.in: rm -f @PWRFAILDIR@/powerfail ./platforms/redhat/apcupsd.spec.in:%define pwrfaildir @PWRFAILDIR@ ./platforms/slackware/rc6.patch.in:+ if [ -f @PWRFAILDIR@/powerfail ]; then ./platforms/slackware/apcupsd.in: rm -f @PWRFAILDIR@/powerfail ./platforms/slackware/rc6.patch.in.old:+ if [ -f @PWRFAILDIR@/powerfail ]; then ./platforms/netbsd/Makefile: echo "if [ -f $(PWRFAILDIR)/powerfail ]; then # TAG_APCUPSD";\ ./platforms/netbsd/apcupsd.in: rm -f @PWRFAILDIR@/powerfail ./platforms/qnx/apccontrol.in: if [ -f @PWRFAILDIR@/powerfail ] ; then ./platforms/qnx/apcupsd.in: rm -f @PWRFAILDIR@/powerfail ./platforms/alpha/awkhaltprog.in: print "if [ -f @PWRFAILDIR@/powerfail ]; then # ###apcupsd###" ./platforms/alpha/apcupsd.in: rm -f @PWRFAILDIR@/powerfail ./platforms/mandrake/awkhaltprog.in: print "if [ -f @PWRFAILDIR@/powerfail ]; then # ***apcupsd***" ./platforms/mandrake/apcupsd.in: rm -f @PWRFAILDIR@/powerfail ./platforms/mandrake/apcupsd.spec.in:%define pwrfaildir @PWRFAILDIR@ ./platforms/suse/awkhaltprog.in: print "if [ -f @PWRFAILDIR@/powerfail ]; then # ***apcupsd***" ./platforms/suse/apcupsd.in: rm -f @PWRFAILDIR@/powerfail ./platforms/suse/apcupsd.spec.in:%define pwrfaildir @PWRFAILDIR@ ./platforms/darwin/apccontrol.in: if [ -f @PWRFAILDIR@/powerfail ] ; then ./platforms/unknown/apcupsd.in: rm -f @PWRFAILDIR@/powerfail ./platforms/unknown/halt.in:if [ -f @PWRFAILDIR@/powerfail ]; then ./platforms/mingw/apcupsd.conf.in:# PWRFAILDIR <path to powerfail directory> ./platforms/mingw/apcupsd.conf.in:PWRFAILDIR @PWRFAILDIR@ ./platforms/mingw/installer/winapcupsd.nsi: ${StrReplace} $2 "@PWRFAILDIR@" "$INSTDIR\etc\apcupsd" $2 ./platforms/openbsd/Makefile: echo "if [ -f $(PWRFAILDIR)/powerfail ]; then # TAG_APCUPSD";\ ./platforms/openbsd/apccontrol.in: if [ -f @PWRFAILDIR@/powerfail ] ; then ./platforms/openbsd/apcupsd.in: rm -f @PWRFAILDIR@/powerfail ./platforms/engarde/awkhaltprog.in: print "if [ -f @PWRFAILDIR@/powerfail ]; then # ***apcupsd***" ./platforms/engarde/apcupsd.in: rm -f @PWRFAILDIR@/powerfail ./platforms/engarde/apcupsd.spec.in: print "if [ -f @PWRFAILDIR@/powerfail ]; then # ***apcupsd***" ./doc/apcupsd.conf.5:.It PWRFAILDIR <path> ./doc/manual/manual.html:-PWRFAILDIR /etc/apcupsd ./doc/manual/manual.html:+PWRFAILDIR /etc/apcupsd/null ./doc/manual/manual.html:<tt class="docutils literal">PWRFAILDIR</tt>, and <tt class="docutils literal">NOLOGINDIR</tt> set to a special "null" directory that I have ./doc/manual/manual.html:<dt><strong>PWRFAILDIR</strong> <em>path to powerfail dir</em></dt> ./doc/manual/manual.rst: -PWRFAILDIR /etc/apcupsd ./doc/manual/manual.rst: +PWRFAILDIR /etc/apcupsd/null ./doc/manual/manual.rst:``PWRFAILDIR``, and ``NOLOGINDIR`` set to a special "null" directory that I have ./doc/manual/manual.rst:**PWRFAILDIR** *path to powerfail dir* ./ReleaseNotes: - PWRFAILDIR (sets location where powerfail file will be written) ./src/lib/apcconfig.c: {"PWRFAILDIR", match_str, WHERE(pwrfailpath), SIZE(pwrfailpath)}, ./src/lib/apcconfig.c: strlcpy(ups->pwrfailpath, PWRFAILDIR, sizeof(ups->pwrfailpath)); ./autoconf/configure.in:# set the default PWRFAILDIR ./autoconf/configure.in:PWRFAILDIR=${sysconfdir} ./autoconf/configure.in: PWRFAILDIR=/var/run ./autoconf/configure.in: PWRFAILDIR=/etc ./autoconf/configure.in:# now allow user to specify PWRFAILDIR ./autoconf/configure.in: [PWRFAILDIR="$withval";]) ./autoconf/configure.in:AC_DEFINE_UNQUOTED(PWRFAILDIR, "$PWRFAILDIR", [Default directory in which powerfail flag file is written]) ./autoconf/configure.in:AC_SUBST(PWRFAILDIR) ./autoconf/configure.in: Power Fail dir ${PWRFAILDIR} ./autoconf/variables.mak.in:PWRFAILDIR = @PWRFAILDIR@ ./autoconf/config.h.in:#undef PWRFAILDIR
This was still a problem that last time that I had a power failure about three months ago. Maybe the change made in relation to https://bugzilla.redhat.com/show_bug.cgi?id=788707 might shed some light?
The origin of this problem relies in the files (search for nologin and NOLOGIN) apcupsd-3.14.14/include/defines.h apcupsd-3.14.14/src/lib/apcconfig.c I hope to be soon able to work on it. In case of urgency you may want to look at this apcupsd alternative https://src.fedoraproject.org/rpms/nut
Personal reminder: function ================== static void prohibit_logins(UPSINFO *ups) { if (ups->nologin_file) return; /* already done */ logonfail(ups, 0); ups->nologin_file = true; log_event(ups, LOG_ALERT, "User logins prohibited"); } ================== in apcupsd-3.14.14/src/action.c
This just happened to me on a Fedora 40 system. To recover the system, I booted with a live USB fedora image. Tracked down the disk partition with the root image and deleted the /etc/nologin file. For me that was an lvm2 partition, which meant a whole bunch of terminal commands (documented for next time I run into this): sudo vgscan sudo vgchange -ay sudo lvs sudo mount /dev/fedora_localhost-live/root /mnt sudo rm /mnt/etc/nologin sudo umount /mnt sync yanked out the boot disk USB and rebooted the machine. I was then able to log in again. Next, I found the line in /etc/apcupsd/apcupsd.conf which defines NOLOGINDIR /etc and replaced it (sudo vi /etc/apcupsd/apcupsd.conf) with NOLOGINDIR /tmp I suspect a better value for this is /var/run/ but I'm not convinced the whole nologin feature is actually a feature for me...
For completeness, the RPM on this system is $ rpm -q apcupsd apcupsd-3.14.14-31.fc40.x86_64
FWIW I found I had to do 1226 rpm updates to refresh my machine to current and then rebooted it, this made the modified apcupsd config effective. I think the way to get the system to refresh directly without a reboot is: sudo systemctl restart apcupsd.service sudo systemctl status apcupsd.service
*** Bug 2295189 has been marked as a duplicate of this bug. ***
*** Bug 2323159 has been marked as a duplicate of this bug. ***
(In reply to Germano Massullo from comment #9) > Personal reminder: > function > ================== > static void prohibit_logins(UPSINFO *ups) > { > if (ups->nologin_file) > return; /* already done */ > > logonfail(ups, 0); > ups->nologin_file = true; > > log_event(ups, LOG_ALERT, "User logins prohibited"); > } > ================== > in apcupsd-3.14.14/src/action.c Within 24 hours I will provide a new build, I will you to test it
FEDORA-2024-1b6c90dbe3 (apcupsd-3.14.14-33.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-1b6c90dbe3
FEDORA-2024-6901970e1a (apcupsd-3.14.14-33.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-6901970e1a
Please test such builds, then login with your FAS account and leave a karma feedback on bodhi. Thank you
FEDORA-2024-1b6c90dbe3 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-1b6c90dbe3` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-1b6c90dbe3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-6901970e1a has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-6901970e1a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-6901970e1a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Germano Massullo from comment #18) > Please test such builds, then login with your FAS account and leave a karma > feedback on bodhi. > Thank you ^^^
So, I did the following: `sudo dnf remove apcupsd` `sudo dnf install apcupsd --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-1b6c90dbe3` This wiped out my workaround version of the config. I followed the advice of https://bugzilla.redhat.com/show_bug.cgi?id=2295189 and replaced this line: `TIMEOUT 0` in the fresh `/etc/apcupsd/apcupsd.conf` config file with `TIMEOUT 30` then did this: `sudo systemctl daemon-reload` `sudo systemctl restart apcupsd.service` `sudo systemctl status apcupsd.service` I disconnected the UPS from power ``` Nov 16 07:22:38 water apcupsd[109084]: Power failure. Nov 16 07:22:44 water apcupsd[109084]: Running on UPS batteries. Nov 16 07:22:44 water apcupsd[109360]: wall: error getting sessions: Permission denied Nov 16 07:22:52 water apcupsd[109084]: Mains returned. No longer on UPS batteries. Nov 16 07:22:52 water apcupsd[109084]: Power is back. UPS running on mains. Nov 16 07:22:52 water apcupsd[109422]: wall: error getting sessions: Permission denied ``` (Not sure what to make of the `wall ... Permission denied` entries.) However, while running on battery, I was not prevented from logging in (I am happy about this!) but it is not the prior behavior. After 30 seconds on battery power, the system halted and ejected all users. Powering the APC and the machine on again, the machine booted and allowed logins. So, the net effect is that I was not prevented from logging in after power on. Good for me! (I'm not sure if anyone else is going to complain about the `/etc/nologin` file no longer being created while the system is on battery. I am not.)
Just realized that log captured my initial experiment to see if logins were prevented while on battery (which they weren't) and not the shutdown which I did with a follow on disconnect of the power.
The only credentials I have for Fedora/Redhat are the ones I'm using for this bug update. The `bodhi` system does not accept them. I'm thus not able to give any "karma" etc there.
FEDORA-2024-1b6c90dbe3 (apcupsd-3.14.14-33.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
> However, while running on battery, I was not prevented from logging in (I am > happy about this!) but it is not the prior behavior. As I understand things, login should not be prevented simply because the system is running on battery but only once the shutdown process has started. I may be mistaken but that is what used to happen before this bug was introduced. /etc/nologin would then be removed upon system restart. > (I'm not sure if anyone else is going to complain about the `/etc/nologin` > file no longer being created while the system is on battery. I am not.) While I think that the "proper" behaviour (whatever that means) should be in place, I am happy to have "improper" behaviour if it means that I can login after power comes back so I, for one, am not going to complain. :-)
FEDORA-2024-6901970e1a (apcupsd-3.14.14-33.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days