NUT, devd and USB interface of UPS

Colleagues, please tell me how I can solve the problem with the USB interface of my UPS.

Some time ago, the daemons of the NUT package decided to run not from the user 'uucp', but from the user 'nut'. I believe that a decision was made to do more correctly and safely.
I installed NUT from /usr/ports and did not do any settings that went beyond the general scope, I just configured the package for my UPS and created accounts for remote machines.

Further, I discovered that after server boot or reboot the corresponding daemon could not connect to the UPS and begin to interact with it. The UPS interface appears in the /dev/usb directory with the owner root and group 'operator'.
However, if you restart the devd daemon and reconnect the UPS cable, then it appears with the group 'nut'. (In exactly that order.)
After this, the NUT package also needs to be restarted.

The nut-scanner will determine the UPS as follows:
Code:
root@server:/home/ogogon # nut-scanner
Scanning USB bus.
No start IP, skipping SNMP
Scanning XML/HTTP bus.
No start IP, skipping NUT bus (old connect method)
Scanning NUT bus (avahi method).
Failed to create Avahi client: Daemon not running
[nutdev1]
    driver = "usbhid-ups"
    port = "auto"
    vendorid = "0D9F"
    productid = "00A3"
    product = "SRT-2000   SRTV1.8"
    serial = "4A3-0000-0001"
    vendor = "POWERCOM Co.,LTD"
    bus = "000"
    device = "002"
    busport = "002"
    ###NOTMATCHED-YET###bcdDevice = "0001"

There is a corresponding entry about him in the /usr/local/etc/devd/nut-usb.conf file:
Code:
#  PowerCOM SKP - Smart KING Pro (all Smart series)  - usbhid-ups
notify 100 {
        match "system"          "USB";
        match "subsystem"       "DEVICE";
        match "type"            "ATTACH";
        match "vendor"          "0x0d9f";
        match "product"         "0x00a3";
        action "chgrp nut /dev/$cdev; chmod g+rw /dev/$cdev";
};

I think everything should be fine. But that's not true.
What am I doing wrong?

Ogogon.
 
This suggests that /usr/local/etc/devd/nut-usb.conf is not read by devd. Check that your devd.conf is configured to read both /etc/devd _and_ /usr/local/etc/devd.
 
I had a similar problem, but I didn't look into details as I needed to get NUT up and running quickly.
All I did was re-plug the USB connector and devd applied the permissions.
But somehow they were not applied on startup.
It seems like maybe a regression in devd or maybe in the code that announces devices to devd.
I noticed the problem on CURRENT.
 
This suggests that /usr/local/etc/devd/nut-usb.conf is not read by devd. Check that your devd.conf is configured to read both /etc/devd _and_ /usr/local/etc/devd.
Thank you for your reply. I checked this and believe that this point is set in the configuration file.
Here is part of the /etc/devd.conf file:
Code:
options {
        # Each "directory" directive adds a directory to the list of
        # directories that we scan for files.  Files are loaded in the order
        # that they are returned from readdir(3).  The rule-sets are combined
        # to create a DFA that's used to match events to actions.
        directory "/etc/devd";
        directory "/usr/local/etc/devd";
        pid-file "/var/run/devd.pid";

        # Setup some shorthand for regex that we use later in the file.
        #XXX Yes, this is gross -- imp
        set wifi-driver-regex
                "(ath|bwi|bwn|ipw|iwlwifi|iwi|iwm|iwn|malo|mwl|otus|ral|rsu|rtw|rtwn|rum|\
                run|uath|upgt|ural|urtw|wpi|wtap|zyd)[0-9]+";
};
I never changed the devd configuration - it worked fine and there was no need.
But I believe that the situation described is some kind of problem in his work.

Maybe somehow you can attract the attention of devd's developers?
 
I had a similar problem, but I didn't look into details as I needed to get NUT up and running quickly.
All I did was re-plug the USB connector and devd applied the permissions.
But somehow they were not applied on startup.
It seems like maybe a regression in devd or maybe in the code that announces devices to devd.
I noticed the problem on CURRENT.
You are describing my situation.
If NUT did not wait for the power to be restored and turned off the machines being serviced, then, after the power supply is restored, this package will not be able to start on its own. You will need to restart (reload) the devd and remove-insert the USB cable from the UPS.
This is impossible without the intervention of an administrator or operator.
 
The /usr/etc/devd set of devd rules is - I think - available sooner than the /usr/local/etc/devd set of rules as a machine boots.

It may be the file system for /usr/local is not yet mounted at the time of the USB attach event so devd does not (yet) know those rules.

Try moving the devd rule from /usr/local/etc to /usr/etc/devd.

This is just a guess.
 
The /usr/etc/devd set of devd rules is - I think - available sooner than the /usr/local/etc/devd set of rules as a machine boots.

It may be the file system for /usr/local is not yet mounted at the time of the USB attach event so devd does not (yet) know those rules.

Try moving the devd rule from /usr/local/etc to /usr/etc/devd.

This is just a guess.
Interesting idea... I moved the file to /etc/devd. Now, after loading the server, the rights are set more or less acceptable.
Code:
root@server:/home/ogogon # ls -alg /dev/usb
total 1
...

crw-rw----   1 root  nut       0x63 20 Feb. 02:16 0.2.0
...

root@server:/home/ogogon #
However, the final result is not achieved.
Code:
Broadcast Message from root@server.ogogon.org                                
        (no tty) at 2:04 GMT+03...                                              
                                                                             
UPS srt2000@localhost is unavailable
And only after the NUT restart (/usr/local/etc/rc.d/nut restart) does the daimon begin to interact with the UPS.
Code:
Broadcast Message from root@server.ogogon.org                                
        (no tty) at 2:06 GMT+03...                                              
                                                                             
Communications with UPS srt2000@localhost established

Perhaps there are several problems at play here...
 
Perhaps NUT is starting too soon. You can edit the REQUIRE clause of the NUT rc script to run after one of the later stages - like all file systems are mounted or networking is up and running. Try "NETWORK" or "LOGIN" in the REQUIRE clause.
 
Perhaps NUT is starting too soon. You can edit the REQUIRE clause of the NUT rc script to run after one of the later stages - like all file systems are mounted or networking is up and running. Try "NETWORK" or "LOGIN" in the REQUIRE clause.
Thank you, I already thought about this. But there, even without my intervention, a completely reasonable set of conditions is indicated.
sh:
#!/bin/sh

# PROVIDE: nut
# REQUIRE: NETWORKING devfs devd syslogd
# BEFORE: LOGIN
# KEYWORD: shutdown
 
And only after the NUT restart (/usr/local/etc/rc.d/nut restart) does the daimon begin to interact with the UPS.

Excuse me if I'm missing the point here, but after booting initially or on power return, how about launching a small task - maybe from /etc/rc.local - with just a sleep 10 (e.g.) then the service NUT [re]start?

Hackish workaround at best, till underlying issue is solved?
 
Excuse me if I'm missing the point here, but after booting initially or on power return, how about launching a small task - maybe from /etc/rc.local - with just a sleep 10 (e.g.) then the service NUT [re]start?

Hackish workaround at best, till underlying issue is solved?
I believe that it will even work. But this is very incorrect.

I believe that we need to ask our respected maintainer to check the operation of the rc-scripts. There's something wrong with them.
 
Dear cy@!
Could you check the operation of the rс-scripts? I think there's something wrong with them.
For example, when restarting or stopping, they miss the pid-file, although it exists and is in the right place.
Code:
root@server:/home/ogogon # ls -alg /var/db/nut
total 20
drwxr-x---   2 nut   nut     7 20 Feb. 06:49 .
drwxr-xr-x  27 root  wheel  38 20 Feb. 06:30 ..
-rw-r--r--   1 nut   nut     5 20 Feb. 06:49 upsd.pid
-rw-r--r--   1 nut   nut     5 20 Feb. 06:30 upslog.pid
-rw-r--r--   1 nut   nut     5 20 Feb. 06:30 upsmon.pid
srw-rw----   1 nut   nut     0 20 Feb. 06:49 usbhid-ups-srt2000
-rw-r--r--   1 nut   nut     5 20 Feb. 06:49 usbhid-ups-srt2000.pid
root@server:/home/ogogon # /usr/local/etc/rc.d/nut restart
Stopping nut.
Waiting for PIDS: 2881.
Network UPS Tools - UPS driver controller 2.8.1
fopen /var/db/nut/usbhid-ups-srt2000.pid: No such file or directory
Network UPS Tools - UPS driver controller 2.8.1
Network UPS Tools - Generic HID driver 0.52 (2.8.1)
USB communication driver (libusb 1.0) 0.46
Using subdriver: PowerCOM HID 0.7
Starting nut.
Network UPS Tools upsd 2.8.1
fopen /var/db/nut/upsd.pid: No such file or directory
Could not find PID file '/var/db/nut/upsd.pid' to see if previous upsd instance is already running!
listening on 0.0.0.0 port 3493
Connected to UPS [srt2000]: usbhid-ups-srt2000
Found 1 UPS defined in ups.conf
                                                                              
Broadcast Message from root@server.ogogon.org                                 
        (no tty) at 6:50 GMT+03:00...                                               
                                                                              
Communications with UPS srt2000@localhost lost                                 
                                                                              
                                                                              
Broadcast Message from root@server.ogogon.org                                 
        (no tty) at 6:50 GMT+03:00...                                               
                                                                              
Communications with UPS srt2000@localhost established
It is possible that something in these scripts no longer corresponds to the current situation. It is possible that startup problems lie somewhere nearby.
 
I think you can ignore the missing pid file warning.

Stopping nut.
Waiting for PIDS: 2881.


The script likely retrieved the pid # above, sent a signal to stop the process, and then deleted the pid file. A later piece of the script checks for the presence and issues that warning - which causes no harm.

Back to your real problem - you never posted the log from NUT a boot time which is when the problem occurs.
 
Dear cy@!
Could you check the operation of the rс-scripts? I think there's something wrong with them.
For example, when restarting or stopping, they miss the pid-file, although it exists and is in the right place.
Code:
root@server:/home/ogogon # ls -alg /var/db/nut
total 20
drwxr-x---   2 nut   nut     7 20 Feb. 06:49 .
drwxr-xr-x  27 root  wheel  38 20 Feb. 06:30 ..
-rw-r--r--   1 nut   nut     5 20 Feb. 06:49 upsd.pid
-rw-r--r--   1 nut   nut     5 20 Feb. 06:30 upslog.pid
-rw-r--r--   1 nut   nut     5 20 Feb. 06:30 upsmon.pid
srw-rw----   1 nut   nut     0 20 Feb. 06:49 usbhid-ups-srt2000
-rw-r--r--   1 nut   nut     5 20 Feb. 06:49 usbhid-ups-srt2000.pid
root@server:/home/ogogon # /usr/local/etc/rc.d/nut restart
Stopping nut.
Waiting for PIDS: 2881.
Network UPS Tools - UPS driver controller 2.8.1
fopen /var/db/nut/usbhid-ups-srt2000.pid: No such file or directory
Network UPS Tools - UPS driver controller 2.8.1
Network UPS Tools - Generic HID driver 0.52 (2.8.1)
USB communication driver (libusb 1.0) 0.46
Using subdriver: PowerCOM HID 0.7
Starting nut.
Network UPS Tools upsd 2.8.1
fopen /var/db/nut/upsd.pid: No such file or directory
Could not find PID file '/var/db/nut/upsd.pid' to see if previous upsd instance is already running!
listening on 0.0.0.0 port 3493
Connected to UPS [srt2000]: usbhid-ups-srt2000
Found 1 UPS defined in ups.conf
                                                                             
Broadcast Message from root@server.ogogon.org                                
        (no tty) at 6:50 GMT+03:00...                                              
                                                                             
Communications with UPS srt2000@localhost lost                                
                                                                             
                                                                             
Broadcast Message from root@server.ogogon.org                                
        (no tty) at 6:50 GMT+03:00...                                              
                                                                             
Communications with UPS srt2000@localhost established
It is possible that something in these scripts no longer corresponds to the current situation. It is possible that startup problems lie somewhere nearby.
I am not able to reproduce your problem here on any of my 15-CURRENT systems. This was not a problem when running 14-CURRENT (now 14-STABLE) either. This suggests some kind of local configuration problem

What is uname -a? Have any rc scripts been locally updated?

Can you post rc.conf, in its entirety, please.

How have you installed nut? Using binary packages or building the port yourself?

A PR or mailing lists are better vehicles for this kind of problem than on forums.
 
Just a couple of lines about my case.
I do not have to restart any services, I just replug the USB cable from the UPS.
Everything is on a single root partition (UFS), so mount order does not play role.
According to rcorder, related services are started in the expected order:
Code:
# rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | grep -E 'devd|nut|mount'
/etc/rc.d/mountcritlocal
/etc/rc.d/autounmountd
/etc/rc.d/devd
/etc/rc.d/mountcritremote
/usr/local/etc/rc.d/nut
/usr/local/etc/rc.d/nut_upslog
/usr/local/etc/rc.d/nut_upsmon

P.S.
I was also able to reproduce the problem on stable/13.
 
Code:
Feb 20 11:15:53 neo kernel: start_init: trying /sbin/init
Feb 20 11:15:53 neo kernel: ugen6.2: <American Power Conversion Smart-UPS 1500 FW:653.19.I USB FW:11.03> at usbus6
Feb 20 11:15:53 neo kernel: awg0: link state changed to UP
Feb 20 11:15:53 neo kernel: lo0: link state changed to UP
Feb 20 11:15:53 neo kernel: awg0: link state changed to DOWN
Feb 20 11:15:53 neo kernel: awg0: link state changed to UP
Feb 20 11:15:53 neo root[820]: /etc/rc: WARNING: failed precmd routine for nut
Feb 20 11:15:53 neo upsmon[827]: UPS [smart1500@localhost]: connect failed: Connection failure: Connection refused
Code:
# ls -l /dev/usb/6.2.*
crw-rw----  1 root uucp 0x52 20 Feb 11:15 /dev/usb/6.2.0
crw-rw----  1 root uucp 0x78 20 Feb 11:15 /dev/usb/6.2.1
There is absolutely nothing about the UPS in devd.log (I have it enabled in syslog.conf) after the startup.



Now I re-plug the cable and check devd.log:
Code:
Feb 20 11:20:50 neo devd[586]: Processing event '!system=USB subsystem=DEVICE type=DETACH ugen=ugen6.2 cdev=ugen6.2 vendor=0x051d product=0x0002 devclass=0x00 devsubclass=0x00 sernum="3S1324X03751" release=0x0006 mode=host port=1 parent=ugen6.1'
Feb 20 11:20:50 neo devd[586]: Processing event '!system=USB subsystem=INTERFACE type=DETACH ugen=ugen6.2 cdev=ugen6.2 vendor=0x051d product=0x0002 devclass=0x00 devsubclass=0x00 sernum="3S1324X03751" release=0x0006 mode=host interface=0 endpoints=1 intclass=0x03 intsubclass=0x00 intprotocol=0x00'
Feb 20 11:20:50 neo devd[586]: Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=ugen6.2'
Feb 20 11:20:50 neo devd[586]: Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=usb/6.2.0'
Feb 20 11:20:50 neo devd[586]: Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=usb/6.2.1'
Feb 20 11:21:03 neo devd[586]: Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=usb/6.2.0'
Feb 20 11:21:03 neo devd[586]: Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=ugen6.2'
Feb 20 11:21:03 neo devd[586]: Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=usb/6.2.1'
Feb 20 11:21:03 neo devd[586]: Processing event '!system=USB subsystem=DEVICE type=ATTACH ugen=ugen6.2 cdev=ugen6.2 vendor=0x051d product=0x0002 devclass=0x00 devsubclass=0x00 sernum="3S1324X03751" release=0x0006 mode=host port=1 parent=ugen6.1'
Feb 20 11:21:03 neo devd[586]: Executing 'chgrp nut /dev/$'ugen6.2'; chmod g+rw /dev/$'ugen6.2''
Feb 20 11:21:03 neo devd[586]: Processing event '!system=USB subsystem=INTERFACE type=ATTACH ugen=ugen6.2 cdev=ugen6.2 vendor=0x051d product=0x0002 devclass=0x00 devsubclass=0x00 sernum="3S1324X03751" release=0x0006 mode=host interface=0 endpoints=1 intclass=0x03 intsubclass=0x00 intprotocol=0x00'
Feb 20 11:21:04 neo devd[586]: Processing event '? at bus=6 hubaddr=1 port=1 devaddr=2 interface=0 ugen=ugen6.2 vendor=0x051d product=0x0002 devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="3S1324X03751" release=0x0006 mode=host intclass=0x03 intsubclass=0x00 intprotocol=0x00 on uhub5'
Feb 20 11:21:04 neo devd[586]: Executing 'service devmatch quietstart $'? at bus=6 hubaddr=1 port=1 devaddr=2 interface=0 ugen=ugen6.2 vendor=0x051d product=0x0002 devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="3S1324X03751" release=0x0006 mode=host intclass=0x03 intsubclass=0x00 intprotocol=0x00 on uhub5''
And
Code:
# ls -l /dev/usb/6.2.*
crw-rw----  1 root nut  0x69 20 Feb 11:21 /dev/usb/6.2.0
crw-rw----  1 root uucp 0x73 20 Feb 11:21 /dev/usb/6.2.1
service nut start is successful now.
 
So, my conclusion is that either the kernel fails to notify about pre-attached USB devices or devd fails to read notifications issued before its start or those notifications get lost somehow.
 
My previous conclusion was wrong (but I kept it for posterity).

devd.log didn't have any entries because devd was started before syslogd. It's the normal configuration.
I hacked rc scripts a bit and got startup logs from devd and everything was as expected in the logs.

After clearing my suspicions about devd I looked around /etc configurations and found the problem.
In my case it was a rule in devfs.rules that set /dev/usb/* group to uucp.
I am not sure why I had that rule.
Anyway, since devfs service is started after devd service, the former overrode whatever the latter did on startup.

When the services are already running, replugging the device was okay because the devfs rule was applied immediately and the devd action was executed a bit later, so devd won.

I am not sure but perhaps devfs used to be started before devd and, so, the problem in my configuration was masked.
 
I am not able to reproduce your problem here on any of my 15-CURRENT systems. This was not a problem when running 14-CURRENT (now 14-STABLE) either. This suggests some kind of local configuration problem

What is uname -a? Have any rc scripts been locally updated?
FreeBSD server.ogogon.org 13.2-RELEASE FreeBSD 13.2-RELEASE releng/13.2-n254617-525ecfdad597 GENERIC amd64.
I haven't modified the rc-scripts.

Can you post rc.conf, in its entirety, please.
Code:
ipv6_enable="YES"
hostname="server.ogogon.org"
keymap="de.kbd"
ifconfig_re0="inet 192.168.1.10 netmask 255.255.255.0"
netwait_enable="YES"
netwait_ip="192.168.1.15"
netwait_if="re0"
defaultrouter="192.168.1.15"
pf_enable="YES"
smartd_enable="YES"
named_enable="YES"
sshd_enable="YES"
ntpdate_enable="YES"
ntpdate_hosts="de.pool.ntp.org"
ntpd_enable="YES"
syslogd_enable="NO"
syslog_ng_enable="YES"
syslog_ng_config="-v"
fail2ban_enable="YES"
asterisk_enable="YES"
dahdi_enable="NO"
dahdi_modules="wctdm24xxp"
dovecot_enable="YES"
php_fpm_enable="YES"
nginx_enable="YES"
nut_enable="YES"
nut_upsmon_enable="YES"
nut_upslog_enable="YES"
nut_upslog_ups="srt2000@localhost"
saslauthd_enable="YES"
sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO" 
spfmilter_enable="YES"
spfmilter_socket="unix:/var/run/spfmilter.sock"
spfmilter_flags="-g \"+a +mx -all\""
miltergreylist_enable="YES"
milterregex_enable="YES"
mysql_enable="YES"
samba_server_enable="YES"
gitea_enable="YES"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="AUTO"
zfs_enable="YES"
ftpd_enable="YES"
ftpd_flags="-l -l"

How have you installed nut? Using binary packages or building the port yourself?
cd /usr/ports/sysutils/nut
make install clean
 
In my case it was a rule in devfs.rules that set /dev/usb/* group to uucp.
I am not sure why I had that rule.
Some time ago, NUT was launched from the user 'uucp'. Then it was changed to his own uid 'nut'.
It appears that not everything in the system environment running this package has been corrected to accommodate this change.
 
Back
Top