Fresh install of NUT - /var/run/nut is not created and permissions not set

[TheKaese]

Hi

Having some serious issues getting NUT running on one of my servers. What's curious is that I'm using the exact same configuration on two systems, but one of them will not create the var/run/nut directory with the correct permissions at boot. I installed NUT using the following commands.

  # apt-get build-dep nut
  # git clone https://github.com/networkupstools/nut.git
  # cd nut ; ./autogen.sh
  # ./configure --includedir=/usr/include --mandir=/usr/share/man \
  --infodir=/usr/share/info --sysconfdir=/etc/nut --localstatedir=/var \
  --libexecdir=/usr/lib/nut --srcdir=. --enable-maintainer-mode \
  --disable-silent-rules --libdir=/usr/lib/`gcc -print-multiarch` \
  --with-ssl --with-openssl --with-cgi --with-dev --enable-static \
  --with-statepath=/var/run/nut --with-altpidpath=/var/run/nut \
  --with-drvpath=/lib/nut --with-cgipath=/usr/lib/cgi-bin/nut \
  --with-htmlpath=/usr/share/nut/www --with-pidpath=/var/run/nut \
  --datadir=/usr/share/nut --with-pkgconfig-dir=/usr/lib/`gcc -print-multiarch`/pkgconfig \
  --with-user=nut --with-group=nut --with-udev-dir=/lib/udev \
  --with-systemdsystemunitdir=/lib/systemd/system
  # make
  # cd drivers ; make ; make install ; cd ../ ; make ; make install
  # mkdir /etc/nut/cert
  # chmod 0755 /etc/nut/cert
  # cd /etc/net/cert
  # openssl req -new -x509 -nodes -out upsd.crt -keyout upsd.key
  # openssl x509 -hash -noout -in upsd.crt
  # cp upsd.crt 122b2de2.0
  # cat upsd.crt upsd.key > upsd.pem
  # chown root:nut upsd.pem
  # chmod 0640 upsd.pem

But nut-server refuses to start due to the permissions issue and the fact that /var/run/nut is not present. If I create the folder manually and give it the correct permissions, things work if I run upsdrvctl start, and then restart nut-server and nut-monitor. But this does not persist after reboot as the /var/run dirs are deleted.

I was able to tailor the service file a bit to get it to create the folders properly:

[Unit]
Description=Network UPS Tools - power devices information server
After=local-fs.target network.target nut-driver.target
# We don't Require drivers to be successfully started! This would be
# a change of behavior compared to init SysV, and could prevent from
# accessing successfully started, at least to audit a system.
Wants=nut-driver.target
# The `upsd` is a networked service (even if bound to a `localhost`)
# so it requires that the OS has some notion of networking already.
# Extending the unit does not require *this* file to be edited, you
# can instead drop in an additional piece of configuration, e.g. add
# a `/etc/systemd/system/nut-server.service.d/network.conf` with:
#   [Unit]
#   Requires=network-online.target
#   After=network-online.target
Requires=network.target
Before=nut-monitor.service
PartOf=nut.target

[Service]
User=nut
Group=nut
EnvironmentFile=-/etc/nut/nut.conf
ExecStart=/usr/local/ups/sbin/upsd
ExecReload=/usr/local/ups/sbin/upsd -c reload
RuntimeDirectory=nut
RuntimeDirectoryMode=0775
Type=forking

[Install]
WantedBy=nut.target

But still, NUT does not start on reboot. But if I run upsdrvctl start, and then restart nut-server and nut-monitor, things are working this updated service file. Seems like the service that is supposed to start the driver is not starting.

This all said - I think there's a bug in the latest version where /var/run/nut is not being created all the time and upsdrvctl is not starting at boot. Unless someone can see something I'm missing?

[jimklimov]

I believe modern Linux systems deliver /var/run as a symlink to /run which is a mountpoint for a tmpfs, so it is recycled during reboot. There is a standard systemd-tmpfiles.service which takes care of creating such locations, and since I didn't have issues on a number of systems where NUT is tested, I was certain a config for that was in the codebase. But indeed, can't find it now with a quick glance. Maybe me or colleagues cobbled something there on particular systems and forgot to commit the experiment to git :\

[jimklimov]

Also, kudos on your patching of the service file. I suppose for a quick win, you would need to similarly patch the unit files for [email protected] and nut-monitor.service.

I am not sure currently with which version of systemd the RuntimeDirectory et al were introduced, but per https://www.freedesktop.org/software/systemd/man/systemd.exec.html we might add use of them for Linux distros going forward at least:

Units with WorkingDirectory=, RootDirectory=, RootImage=, RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory= or ConfigurationDirectory= set automatically gain dependencies of type Requires= and After= on all mount units required to access the specified paths. This is equivalent to having them listed explicitly in RequiresMountsFor=.

So that could cover NUT pid files and state files (e.g. sockets where that upsd talks to drivers).

On a separate note, your configuration did not set a --prefix=... so installation defaulted, at least partially, to /usr/local/... - is that what you intended?

[TheKaese]

@jimklimov, I didn't intend for that that to default, but it's of no consequence on my end. It doesn't really matter where the files are to me, as long as they run.. :)
Though I'm curious about your fix. Looking at the code, are you adding another flag to the configure options? I checked out your code and ran it locally, with the same issues as previous, but I think it's because I'm not setting the new flag. I'll have to dig some more later on.

[jimklimov]

In the ./configure run on a Linux system it should now report something like this without any arguments:

:; ./autogen.sh && ./configure
...
checking whether to install systemd unit files... no
checking whether to install systemd shutdown files... no
checking whether to install systemd tmpfiles files... using /usr/lib/tmpfiles.d
...
config.status: creating scripts/systemd/nut-common.tmpfiles
config.status: creating scripts/systemd/[email protected]
config.status: creating scripts/systemd/nut-monitor.service
config.status: creating scripts/systemd/nut-server.service
config.status: creating scripts/systemd/nut-driver-enumerator.service
config.status: creating scripts/systemd/nut-driver-enumerator.path
config.status: creating scripts/systemd/nutshutdown

based on detected presence of systemd features; with the tmpfiles config make-installed regardless of enablement of other systemd units (they make sense for SYSV style init scripts too, if the OS would provide the temporary locations). Note you (or generally a package post-install script) would need to run systemd-tmpfiles --create to apply any currently present configurations after the installation.

For a configuration with options for actual unit files like below, it should also apply those:

:; ./autogen.sh && ./configure --with-user=nut --with-group=ups --with-systemdsystemunitdir
...
checking whether to install systemd unit files... using /lib/systemd/system
checking whether to install systemd shutdown files... using /lib/systemd/system-shutdown
checking whether to install systemd tmpfiles files... using /usr/lib/tmpfiles.d

with generated contents like:

jim@debian:~/nut$ cat scripts/systemd/nut-common.tmpfiles.in 
# State file (e.g. upsd to driver) and pidfile location for NUT:
d @STATEPATH@/nut 0770 @RUN_AS_USER@ @RUN_AS_GROUP@ - -
X @STATEPATH@/nut
d @PIDPATH@/nut 0770 @RUN_AS_USER@ @RUN_AS_GROUP@ - -
X @PIDPATH@/nut

jim@debian:~/nut$ cat scripts/systemd/nut-common.tmpfiles    
# State file (e.g. upsd to driver) and pidfile location for NUT:
d /var/state/ups/nut 0770 nut ups - -
X /var/state/ups/nut
d /var/run/nut 0770 nut ups - -
X /var/run/nut

Note that currently nut-common.tmpfiles.in is also generated, since there are several path variables that may have same or different values configured, so configure creates a unique set as the .in template based on these choices and then populates it with values like any other template conversion. Clumsy, but least-resistance :)

[jimklimov]

@TheKaese : hi, after my earlier comment, I posted some more commits to polish the https://github.com/jimklimov/nut/tree/systemd-tmpfiles branch (source for PR #1037) - can you check to confirm if that would solve your issue?

Note you would still have to make && sudo make install && sudo systemd-tmpfiles --create I suppose, to impact the system paths as root...

Also note that systemd may complain about use of "/var/run" instead of "/run" - that is noisy but harmless and may also be addressed separately later.

[TheKaese]

Sure, I'll give it a go when I get a chance this week.

[TheKaese]

Hmm.. I'm not getting that output. The only things systemd I see in the output of .configure is:

...
checking whether to install systemd files... using /lib/systemd/system
...
config.status: creating scripts/systemd/Makefile
config.status: creating scripts/systemd/[email protected]
config.status: creating scripts/systemd/nut-monitor.service
config.status: creating scripts/systemd/nut-server.service
config.status: creating scripts/systemd/nut-driver-enumerator.service
config.status: creating scripts/systemd/nut-driver-enumerator.path
config.status: creating scripts/systemd/nutshutdown

I'm still using the same .configure command as my original post, by the way. So my steps have been:

  # git clone https://github.com/jimklimov/nut.git
  # cd nut ; ./autogen.sh
  # ./configure --includedir=/usr/include --mandir=/usr/share/man \
  --infodir=/usr/share/info --sysconfdir=/etc/nut --localstatedir=/var \
  --libexecdir=/usr/lib/nut --srcdir=. --enable-maintainer-mode \
  --disable-silent-rules --libdir=/usr/lib/`gcc -print-multiarch` \
  --with-ssl --with-openssl --with-cgi --with-dev --enable-static \
  --with-statepath=/var/run/nut --with-altpidpath=/var/run/nut \
  --with-drvpath=/lib/nut --with-cgipath=/usr/lib/cgi-bin/nut \
  --with-htmlpath=/usr/share/nut/www --with-pidpath=/var/run/nut \
  --datadir=/usr/share/nut --with-pkgconfig-dir=/usr/lib/`gcc -print-multiarch`/pkgconfig \
  --with-user=nut --with-group=nut --with-udev-dir=/lib/udev \
  --with-systemdsystemunitdir=/lib/systemd/system
  # cd drivers ; make ; make install ; cd ../ ; make ; make install

This all said, it DOES appear to work. Running the above appears to have replaced the changes I had made to the startup scripts, and a reboot of the system results in the nut services starting up without issue.

[jimklimov]

@TheKaese : looking back at your post, I think the git clone you did from my fork took the default branch, not one for these referenced PRs, so might not include the fixes at that point. (Unless you skipped some branch-related options while copy-pasting the screenshot)

Anyway, currently all my ideas on this matter should be part of NUT master branch codebase, so it would be nice if you could check again that this issue got solved for your use-case?

[jimklimov]

May be related to #1212