nut-driver attempts to start when mode=netclient in nut.conf

Bug #1901659 reported by Andrew
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
nut (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

Nut seems to have three systemd units. When nut.conf contains "mode=netclient", there is a lengthy delay to system startup / shutdown because nut-driver cannot start/stop (the UPS is remote, so the user will have either not configured this file, or it will not find an attached UPS where one has been configured). Overall, this is not a very serious bug, but it adds >90 seconds to reboot time...long enough that I eventually got annoyed enough to spend time figuring out why...

Current outcome:

nut-server - attempts to start/stop, detects mode=netclient, writes status message and moves on (OK)
nut-driver - attempts to start/stop, configuration error, waits a long time before failing to start/stop (problem)
nut-client - attempts to start/stop, succeeds as required (OK).

Desired outcome:

nut-server - attempts to start/stop, detects mode=netclient, writes status message and moves on
nut-driver - attempts to start/stop, detects mode=netclient, writes status message and moves on
nut-client - attempts to start/stop, succeeds as required

Log output /var/log/syslog:

Oct 27 18:28:48 yggdrasil systemd[1]: nut-driver.service: Control process exited, code=exited, status=1/FAILURE
Oct 27 18:28:48 yggdrasil systemd[1]: nut-driver.service: Failed with result 'exit-code'.

Workaround:

This can be worked around by removing the nut package and only installing nut-client, but the configuration files suggest that setting mode=netclient should work. At the very least, the comment in nut.conf above this line should be updated to state that you should only install nut-client if you're planning to configure with mode=netclient.

Ubuntu Version:

20.10, 20.04 definitely...probably as long as systemd has been around.

Package Version:

2.7.4-12ubuntu1

Revision history for this message
Andrew (caeci11iusad1) wrote :

I might add that the most noticable time-based impact here is on the shutdown end of things, rather than startup. It does take some time to fail on startup, but on shutdown it seems to have a 90 second wait before it fails...

Revision history for this message
Sergio Durigan Junior (sergiodj) wrote :

Thank you for taking the time to file a bug report.

I don't have a remote UPS readily available to test, so I did my best to set up nut locally (using its dummy.dev interface) inside a Focal container, and then set MODE=netclient in the nut.conf file. I could not reproduce the bug you reported. nut-driver.service did not start:

Oct 28 20:06:03 bla systemd[1]: Stopping Network UPS Tools - power device driver controller...
Oct 28 20:06:03 bla upsdrvctl[13898]: Network UPS Tools - UPS driver controller 2.7.4
Oct 28 20:06:03 bla dummy-ups[13896]: Signal 15: exiting
Oct 28 20:06:03 bla systemd[1]: nut-driver.service: Succeeded.
Oct 28 20:06:03 bla systemd[1]: Stopped Network UPS Tools - power device driver controller.

I thought it was because the dummy.dev trick was interfering with the test, so I fired up a Groovy container, and configured it to connect to the Focal container by editing /etc/nut/upsmon.conf like:

MONITOR dummy-dev1@10.101.133.205 1 monuser pass master

Then, I configured the Focal container with MODE=standalone (so that the server would start and accept connections), and the Groovy container as MODE=netclient. This time, nut-driver simply failed to start, but that's because I did not configure anything else other than /etc/nut/upsmon.conf:

Oct 28 20:09:59 nut-bug1901659 upsdrvctl[1543]: Error: no UPS definitions found in ups.conf
Oct 28 20:09:59 nut-bug1901659 upsdrvctl[1543]: Network UPS Tools - UPS driver controller 2.7.4
Oct 28 20:09:59 nut-bug1901659 systemd[1]: Starting Network UPS Tools - power device driver controller...
Oct 28 20:09:59 nut-bug1901659 systemd[1]: nut-driver.service: Control process exited, code=exited, status=1/FAILURE
Oct 28 20:09:59 nut-bug1901659 systemd[1]: nut-driver.service: Failed with result 'exit-code'.
Oct 28 20:09:59 nut-bug1901659 systemd[1]: Failed to start Network UPS Tools - power device driver controller.

Which seems OK-ish to me. In other words, I could not replicate the 90-second timeout you mentioned in the report by doing these local tests.

For the reasons I explained above, I am marking this bug as Incomplete. I would also like to request more information from you: your configuration files (without the passwords, of course) would be helpful in trying to understand your setup and what might be causing this timeout.

Since there is not enough information in your report to begin triage or to
differentiate between a local configuration problem and a bug in Ubuntu, I
am marking this bug as "Incomplete". We would be grateful if you would:
provide a more complete description of the problem, explain why you
believe this is a bug in Ubuntu rather than a problem specific to your
system, and then change the bug status back to "New".

For local configuration issues, you can find assistance here:
http://www.ubuntu.com/support/community

Changed in nut (Ubuntu):
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for nut (Ubuntu) because there has been no activity for 60 days.]

Changed in nut (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.