Description of problem: apcupsd is unable to talk to ups, when started via systemctl. It works fine, when started manually from root console or from crontab @reboot. Configuration changes from default (/etc/apcupsd/apcupsd.conf): UPSCABLE smart UPSTYPE apcsmart DEVICE /dev/ttyUSB0 Version-Release number of selected component: apcupsd-3.14.12-1.el7.x86_64 How reproducible: every time Steps to Reproduce: 1. systemctl start apcupsd.service Actual results: # apcaccess status | grep STATUS STATUS : COMMLOST Expected results: # apcaccess status | grep STATUS STATUS : ONLINE Additional info: Works fine when started manually or from crontab with @reboot. So the problem somehow is related to how the service is started from systemctl. # systemctl stop apcupsd.service # /sbin/apcupsd -f /etc/apcupsd/apcupsd.conf # apcaccess status | grep STATUS STATUS : ONLINE apctest is able access ups data just fine. I am using USB to serial adapter. # apcaccess status | egrep '(CABLE|DRIVER|MODEL)' CABLE : Custom Cable Smart DRIVER : APC Smart UPS (any) MODEL : SMART-UPS 700
I've just taken over this package and am looking through the tickets. I this still an issue? The issue is most likely selinux related, but you didn't include any audit logs. Since it's been a year, there's a pretty good chance that the RHEL selinux policy has changed.
I'm using modbus over USB (APC SMT750i) and I have similar problem. Here's policy generated by audit2allow which resolved my issue: module apcupsd_local 1.0; require { type apcupsd_t; class netlink_kobject_uevent_socket { bind create getattr setopt }; } #============= apcupsd_t ============== allow apcupsd_t self:netlink_kobject_uevent_socket { bind create getattr setopt };
This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component.
Is this problem still an issue?
Hi all, I ran into the same problem after updating from kernel 5.4.17 (oracle linux 8.6 uek6) to 5.15.0 (oracle linux 8.6 uek7). Unfortunately, the selinux policy snippet from https://bugzilla.redhat.com/show_bug.cgi?id=1236125#c2 did not resolve the issue for me, neither did permissive mode. Audit.log: ---%snip%--- type=DAEMON_ROTATE msg=audit(1657270680.004:7248): op=rotate-logs auid=0 pid=22439 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=success type=SERVICE_START msg=audit(1657270700.745:779): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=apcupsd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' type=AVC msg=audit(1657270700.790:780): avc: denied { nnp_transition } for pid=22500 comm="(apcupsd)" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:apcupsd_t:s0 tclass=process2 permissive=1 type=SYSCALL msg=audit(1657270700.790:780): arch=c000003e syscall=59 success=yes exit=0 a0=56191d5d8900 a1=56191d6e28c0 a2=56191d4c33e0 a3=56191d5d8b40 items=1 ppid=1 pid=22500 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="apcupsd" exe="/usr/sbin/apcupsd" subj=system_u:system_r:apcupsd_t:s0 key=(null) type=BPRM_FCAPS msg=audit(1657270700.790:780): fver=0 fp=0 fi=0 fe=0 old_pp=000001ffffffffff old_pi=0 old_pe=000001ffffffffff old_pa=0 pp=000001fff7fcffff pi=0 pe=000001fff7fcffff pa=0 frootid=0 type=EXECVE msg=audit(1657270700.790:780): argc=4 a0="/sbin/apcupsd" a1="-b" a2="-f" a3="/etc/apcupsd/apcupsd.conf" type=CWD msg=audit(1657270700.790:780): cwd="/" type=PATH msg=audit(1657270700.790:780): item=0 name="/lib64/ld-linux-x86-64.so.2" inode=12625931 dev=fc:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PROCTITLE msg=audit(1657270700.790:780): proctitle=2F7362696E2F61706375707364002D62002D66002F6574632F617063757073642F617063757073642E636F6E66 type=SERVICE_STOP msg=audit(1657270733.578:788): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=apcupsd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' ---%snip%---
EPEL 7 entered end-of-life (EOL) status on 2024-06-30.\n\nEPEL 7 is no longer maintained, which means that it\nwill not receive any further security or bug fix updates.\n As a result we are closing this bug.