{Question} Apple MacOS Sonoma & NUT-client (not working)

[JordyWingelaar]

{Question} Apple MacOS Sonoma & NUT-client (not working)

[jimklimov]

Maybe @clepple might chime in...

In the meanwhile, can you please elaborate on the problem? What you've tried, what works, what does not, what are the configs, what NUT version, are there any logs or daemon messages to share?

• Is it a communications problem (e.g. upsc or telnet your-nut-server 3493 also fail) => firewalls?
• Is it a credentials problem (simple clients connect, upsmon does not) => check the user/pass in MONITOR lines of upsmon.conf
• Is it a permissions problem (monitoring sort of works, but shutdowns do not) => check for starting as root or using a SHUTDOWNCMD which allows elevating
• etc...

[JordyWingelaar]

Thanks for the quick reply Jim!

Attached you can find my settings.
For your information:

• The Rasberry PI4 4gb model is acting as nut-server (version 2.8.0-7). The device has Ubuntu 23.10 installed and has no active firewalls. The connection to the network is made with an static IP-adress (192.168.2.164).
• The MacMini Bootcamp (Windows 10 Pro) is acting as nut-client. The device also has no active firewalls and is connected with an static IP-adress (192.168.2.162). The connection to the nut-server is made with WINnut version 2.1.774.35837). Attached you can find the settings configured in Win-nut.
• The macmini MacOS (MacOS Sonoma) is acting as nut-client. This device also has no active firewalls and is also connected with an static IP-adress (192.168.2.161). The nut-client (version 2.7.4) is installed thru Macports.
  There are no other devices connected to this network and it is disconnected from the internet at the moment.

Connection is established between the Win-nut client and the nut-server and no problems are found here.
When connecting the Macos device to the nut-server, I can read the UPS connected to the RasberryPI by using the command upsc [email protected].

Configuration on the rasberryPI4 (NUT-server):

Configuration on the Win-nut client (this is working):

Configuration on the MacOS Sonoma client (not working):

I think the communication is fine since I can read out information using the upsc command, however when the UPS gets disconnected from the RasberryPI, the MacOS device doesn't react to it... Perhaps I'm forgetting anything is this configuration?

[JordyWingelaar]

In addition, I have configured another Linux Ubuntu device as an nut-client. With the same settings as I have configured in MacOS, the new Ubuntu device directly establishes a connection and prompts a pop-up when the UPS is disconnected from my RasberryPI.

This means the nut-server is working correctly, and a connection between server and clients can be made. However, the MacOS device is still not working...

[jimklimov]

Thanks for the report with configs (I guess you'd have to change the pass later on). One thing that pops out is that you do not need the drivers and data server (upsd) on the mac-mini, if it does not have an UPS directly connected as a data source.

For auto-shutdowns you only need the upsmon part. Note it does not generally require RUN_AS_USER root (on most systems at least), so after you get this all set up - check if you can avoid that potential insecurity. Normally upsmon does start as root, then forks and leaves a privileged process only to run the SHUTDOWNCMD eventually (after a message from the unprivileged child that does the bulk of work and networking in particular).

For general monitoring UI you can try the NUT-Monitor python script (provided in sources) or wmNUT (X11 compilable), for example.

I am not sure how NUT is packaged in Macports, maybe it has an all-in-one init script and you'd need to comment away attempts to start the drivers (maybe via upsdrvctl) and upsd, if it does not consider settings from nut.conf.

The last screenshot showed how you start the upsd as your user account, so it likely does not have access to NUT state path (/opt/local/var/db/ups there). The crucial part is whether upsmon does start (beginning life as root, maybe via sudo etc.), and not complain?..

[clepple]

I haven't used Macports in a while (and not with NUT), so all I know is what the ports file says: https://github.com/macports/macports-ports/blob/7e7f39725b6d7987fd4b9619600b00e129fcb549/sysutils/nut/Portfile

I don't see anything in particular that starts upsmon as a server, so it probably needs a launchd plist file (unless some other part of Macports handles that).

[JordyWingelaar]

I've changed the upsd configuration, since the UPS is not directly connected thru usb on the macmini.

I've also created a plist file to start the upsmon. This is now loaded at boot.

[jimklimov]

The ProgramArguments look wrong, -c cmd is for sending signals to a running upsmon (e.g. reload config or initiate forced shutdown). Also, should the path to program be there somewhere - or is it guessed by the label or somehow passed externally?.. If the first line of ProgramArguments is to specify the program, drop the .conf path and use the binary path there?.. :)

Also note that the path to config is normally built in (can be overridden at run time via environment variables, at least since 2.8.0 maybe earlier), so per upsd examples - it would check /opt/local/etc already.

In the second screenshot, you still sudo upsd (starting directly the data server, which you decided to not use and which indeed is not configured to serve any devices from the effectively empty ups.conf). So now it has the needed FS access to read the state path and config, and correctly fails as not-configured. (The early lack of PID reported by many NUT daemons is okay - means no earlier instance is running; newer NUT versions are clearer about wording that.)

[JordyWingelaar]

Thanks, I'm quite a newby if it comes to the command line usage so my bad for the incorrect arguments.

I'm guessing it should look something like this then...?

Please correct me if I'm wrong:)

[jimklimov]

Sorry, I don't have a Mac so can't delve into such level of detail; never saw those launcher configs before and do not know even if this is the only file involved... Maybe others (@clepple ?) can elaborate more though.

[clepple]

Finally had a chance to dig into the archives - here is a branch where I was experimenting with launchd plists:

https://github.com/networkupstools/nut/tree/osx_launchd/scripts/launchd

Theoretically, you should be able to copy the org.networkupstools.upsmon.plist.in file to org.networkupstools.upsmon.plist, replace @SBINDIR@ with the directory where upsmon is installed in MacPorts (maybe in one of the screenshots? dunno, hard to search), and leave the -D argument after that to keep upsmon from forking into the background. ProgramArguments in a plist is like the argv array in a C program: argv[0] is the program name, and items starting from argv[1] are the remaining items from starting it from the command line.

I last used a version of these scripts on OS X 10.15, so definitely refer to the Apple documentation or newer tutorials to make sure things haven't changed.

Also, I don't know the current feature set for the free vs paid versions, but at one point, Lingon was IMHO one of the best launchd plist editors around: https://www.peterborgapps.com/lingon/ (speaking for myself, not an endorsement from my employer, etc. etc.)

[clepple]

@jimklimov I'm not saying this branch is ready to merge, but if someone wanted to do that, it would probably be good to at least update the README to reference the systemd unit generation for drivers (and whatever the equivalent is for OpenIndiana): https://github.com/networkupstools/nut/blob/osx_launchd/scripts/launchd/README.adoc?plain=1#L9-L11

Due to the current state of affairs with user-mode USB on macOS, I don't know if people are really going to want to do much with running multiple drivers there, but I guess there are serial, network, dummy, and native drivers.

[JordyWingelaar]

After researching some information and with the help of some other programmes, We've taken the following steps:

Created a shutdown script: sudo nano /opt/local/etc/shutdown.applescript

Edited the upsmon.conf file: sudo nano /opt/local/etc/upsmon.conf

Edited the upsmon.plist file: sudo nano /Library/LaunchDaemons/org.networkupstools.upsmon.plist

Enable upsmon.plist file: sudo launchctl load -w /Library/LaunchDaemons/org.networkupstools.upsmon.plist

Edited the upsschedule file: sudo nano /opt/local/etc/upssched.conf

Created a command file for executing shutdown: sudo nano /opt/local/bin/upssched-cmd

However, still no luck with executing a proper shutdown:(
Since I have no idea what I'm missing, and the folks that helped me with these extra steps also don't see what we are missing, I am hoping you have the winning answer to solve this case...

[JordyWingelaar]

By the way, here you can find a overview of nut installed by MacPorts

[JordyWingelaar]

Since it felt like I was not getting anywhere, I tried a different approach, just to see if NUT-server will work when the UPS is connected to MacOS and windows would act as an client. This is not the desired setup, but is just to test out.

I've created a clean mac-os disk with Catalina installed on it. Plugged the APC ES550 UPS directly to the macmini and tried to let the macmini act as the nut-server. After installing the nut-server (with BREW this time) I configured the nut-server the way I believe is correct.
When booting the macmini, it directly opens a terminal interface and showing a connection error. I guess this means the nut-server is started automatically at boot.

However, as said, there seems to be an issue with the macosx-ups drivers (since it can not communicate with the UPS)... So, once again, I'm stuck:(

Fault error in macos terminal: "Error connection failure: Connection refused".

[clepple]

When booting the macmini, it directly opens a terminal interface and showing a connection error. I guess this means the nut-server is started automatically at boot.

I wouldn't expect a connection error if upsd is running but the driver is not - it should say something about stale data. Do you see upsd in the output of ps auxww?

However, as said, there seems to be an issue with the macosx-ups drivers (since it can not communicate with the UPS)... So, once again, I'm stuck:(

What debug output do you get from the driver?

As with MacPorts, I don't use the Homebrew package of NUT, so I'm not sure where they install the driver - so if you need help with the command line for debug output, I'll need to know what the full path is for the driver.

[clepple]

I got a little time to retest the macosx-ups driver on Sonoma. For some reason, the OS wasn't noticing the UPS, so there was no power icon on the menu bar, and no battery icon in the Energy Saver section of System Settings. Eventually I jiggled the cables enough and it came up.

This might be a shortcut if the driver is giving you trouble for other reasons:

$ cat <<EOF > psinfo.swift
import IOKit.ps

let psInfo = IOPSCopyPowerSourcesInfo().takeRetainedValue()
print(psInfo)
EOF
$ swift psinfo.swift

If you get an empty array (see below), then the OS isn't properly recognizing the UPS, and there isn't much that macosx-ups can do. Otherwise, you should see some facts about the UPS.

(
)