Bug#961474: nut-client can't be run without nut-server installed
On Sun, Oct 18, 2020 at 12:24:23PM +0200, Laurent Bigonville wrote: > Le 17/10/20 à 19:05, David Engel a écrit : > > On Sat, Oct 17, 2020 at 10:42:30AM +0200, Laurent Bigonville wrote: > > > This is quite weird, the package already contains a systemd tmpfiles > > > snippet > > > (/usr/lib/tmpfiles.d/nut-client.conf) that should create the directory > > > during the boot. > > I see the /usr/lib/tmpfiles.d/nut-client.conf now. It's been nearly 5 > > months since I filed that report so I don't remember any of the > > details. It's quite possible, though, that I ran into the problem > > right after installing the nut-client package without rebooting. If > > that tmpfiles.d file doesn't create the directory until the next boot, > > that could explain the problem. > Thanks for the reply, it's really weird, the /run/nut directory should > created on installation (I just tried that in a chroot and the directory is > properly created) and then recreated on reboot as well as /run is supposed > to be on tmpfs > > > Could you please give me the output of "systemctl list-dependencies > > > nut-monitor.service" > > Here is that output: > From the output, the systemd-tmpfiles-setup.service service is called before > nut-client, so looks like the ordering is OK > > Did you try to uninstall the nut-server package and see if everything is > still working? Is /var/run a symlink to /run on your system? You're in luck. I had a kernel update waiting for me this morning so I removed nut-server and rebooted. All looks good! Thanks for you help. David -- David Engel da...@istwok.net
Bug#961474: nut-client can't be run without nut-server installed
Le 17/10/20 à 19:05, David Engel a écrit : On Sat, Oct 17, 2020 at 10:42:30AM +0200, Laurent Bigonville wrote: This is quite weird, the package already contains a systemd tmpfiles snippet (/usr/lib/tmpfiles.d/nut-client.conf) that should create the directory during the boot. I see the /usr/lib/tmpfiles.d/nut-client.conf now. It's been nearly 5 months since I filed that report so I don't remember any of the details. It's quite possible, though, that I ran into the problem right after installing the nut-client package without rebooting. If that tmpfiles.d file doesn't create the directory until the next boot, that could explain the problem. Thanks for the reply, it's really weird, the /run/nut directory should created on installation (I just tried that in a chroot and the directory is properly created) and then recreated on reboot as well as /run is supposed to be on tmpfs Could you please give me the output of "systemctl list-dependencies nut-monitor.service" Here is that output: From the output, the systemd-tmpfiles-setup.service service is called before nut-client, so looks like the ordering is OK Did you try to uninstall the nut-server package and see if everything is still working? Is /var/run a symlink to /run on your system?
Bug#961474: nut-client can't be run without nut-server installed
On Sat, Oct 17, 2020 at 10:42:30AM +0200, Laurent Bigonville wrote: > This is quite weird, the package already contains a systemd tmpfiles snippet > (/usr/lib/tmpfiles.d/nut-client.conf) that should create the directory > during the boot. I see the /usr/lib/tmpfiles.d/nut-client.conf now. It's been nearly 5 months since I filed that report so I don't remember any of the details. It's quite possible, though, that I ran into the problem right after installing the nut-client package without rebooting. If that tmpfiles.d file doesn't create the directory until the next boot, that could explain the problem. > Could you please give me the output of "systemctl list-dependencies > nut-monitor.service" Here is that output: nut-monitor.service ● ├─system.slice ● └─sysinit.target ● ├─apparmor.service ● ├─dev-hugepages.mount ● ├─dev-mqueue.mount ● ├─keyboard-setup.service ● ├─kmod-static-nodes.service ● ├─nftables.service ● ├─proc-sys-fs-binfmt_misc.automount ● ├─sys-fs-fuse-connections.mount ● ├─sys-kernel-config.mount ● ├─sys-kernel-debug.mount ● ├─sys-kernel-tracing.mount ● ├─systemd-ask-password-console.path ● ├─systemd-binfmt.service ● ├─systemd-boot-system-token.service ● ├─systemd-hwdb-update.service ● ├─systemd-journal-flush.service ● ├─systemd-journald.service ● ├─systemd-machine-id-commit.service ● ├─systemd-modules-load.service ● ├─systemd-pstore.service ● ├─systemd-random-seed.service ● ├─systemd-sysctl.service ● ├─systemd-sysusers.service ● ├─systemd-tmpfiles-setup-dev.service ● ├─systemd-tmpfiles-setup.service ● ├─systemd-udev-trigger.service ● ├─systemd-udevd.service ● ├─systemd-update-utmp.service ● ├─cryptsetup.target ● ├─local-fs.target ● │ ├─-.mount ● │ ├─opus1.mount ● │ ├─systemd-fsck-root.service ● │ ├─systemd-remount-fs.service ● │ └─tmp.mount ● └─swap.target ● └─var-swap-swapfile0.swap > and "systemctl list-dependencies --after > nut-monitor.service" ? Any here is this output: nut-monitor.service ● ├─nut-server.service ● ├─system.slice ● ├─systemd-journald.socket ● ├─basic.target ● │ ├─-.mount ● │ ├─tmp.mount ● │ ├─paths.target ● │ │ ├─systemd-ask-password-console.path ● │ │ └─systemd-ask-password-wall.path ● │ ├─slices.target ● │ │ ├─-.slice ● │ │ ├─system.slice ● │ │ └─user.slice ● │ ├─sockets.target ● │ │ ├─cups.socket ● │ │ ├─dbus.socket ● │ │ ├─syslog.socket ● │ │ ├─systemd-initctl.socket ● │ │ ├─systemd-journald-audit.socket ● │ │ ├─systemd-journald-dev-log.socket ● │ │ ├─systemd-journald.socket ● │ │ ├─systemd-networkd.socket ● │ │ ├─systemd-udevd-control.socket ● │ │ ├─systemd-udevd-kernel.socket ● │ │ └─uuidd.socket ● │ └─sysinit.target ● │ ├─apparmor.service ● │ ├─dev-hugepages.mount ● │ ├─dev-mqueue.mount ● │ ├─emergency.service ● │ ├─kmod-static-nodes.service ● │ ├─modprobe@drm.service ● │ ├─proc-sys-fs-binfmt_misc.automount ● │ ├─sys-fs-fuse-connections.mount ● │ ├─sys-kernel-config.mount ● │ ├─sys-kernel-debug.mount ● │ ├─sys-kernel-tracing.mount ● │ ├─systemd-binfmt.service ● │ ├─systemd-hwdb-update.service ● │ ├─systemd-journald.service ● │ ├─systemd-machine-id-commit.service ● │ ├─systemd-modules-load.service ● │ ├─systemd-pstore.service ● │ ├─systemd-sysctl.service ● │ ├─systemd-sysusers.service ● │ ├─systemd-tmpfiles-setup-dev.service ● │ ├─systemd-tmpfiles-setup.service ● │ ├─systemd-udev-settle.service ● │ ├─systemd-udev-trigger.service ● │ ├─systemd-udevd.service ● │ ├─systemd-update-utmp.service ● │ ├─cryptsetup.target ● │ │ ├─systemd-ask-password-console.path ● │ │ └─systemd-ask-password-wall.path ● │ ├─emergency.target ● │ │ └─emergency.service ● │ ├─local-fs.target ● │ │ ├─run-user-1000.mount ● │ │ ├─systemd-fsck-root.service ● │ │ ├─systemd-remount-fs.service ● │ │ ├─tmp.mount ● │ │ └─local-fs-pre.target ● │ │ ├─keyboard-setup.service ● │ │ ├─systemd-remount-fs.service ● │ │ └─systemd-tmpfiles-setup-dev.service ● │ └─swap.target ● │ └─var-swap-swapfile0.swap ● ├─local-fs.target ● │ ├─run-user-1000.mount ● │ ├─systemd-fsck-root.service ● │ ├─systemd-remount-fs.service ● │ ├─tmp.mount ● │ └─local-fs-pre.target ● │ ├─keyboard-setup.service ● │ ├─systemd-remount-fs.service ● │ └─systemd-tmpfiles-setup-dev.service ● ├─network.target ● │ ├─ifup@enp5s0.service ● │ ├─ifupdown-pre.service ● │ ├─networking.service ● │ ├─systemd-networkd.service ● │ └─network-pre.target ● │ └─nftables.service ● └─sysinit.target ● ├─apparmor.service ● ├─dev-hugepages.mount ● ├─dev-mqueue.mount ● ├─emergency.service ● ├─kmod-static-nodes.service ● ├─modprobe@drm.service ● ├─proc-sys-fs-binfmt_misc.automount ● ├─sys-fs-fuse-connections.mount ● ├─sys-kernel-config.mount ● ├─sys-kernel-debug.mount ● ├─sys-kernel-tracing.mount ● ├─systemd-binfmt.service ● ├─systemd-hwdb-update.service ● ├─systemd-journald.service ● ├─systemd-machine-id-commit.service ● ├─systemd-modules-load.service ●
Bug#961474: nut-client can't be run without nut-server installed
On Sun, 24 May 2020 17:35:10 -0500 David Engel wrote: > Dear Maintainer, Hello David, > > I have two systems connected to a single UPS. The first system > running both nut-server and nut-client packages works fine. The > second system running only nut-client experiences this problem. > > Systemd can't sucessfully start the nut-monitor.service. The reason > is that the /run/nut directory does not exist for upsmon to write its > pid file. Even though upsmon starts and connects to the remote > server, systemd eventually kills it becuase the pid file never gets > written. > > The undesirable work around is to install the nut-server package so > that something run by it creates /run/nut before upsmon is run. This > also results in systemd attempting and failing to start the nut-driver > service. The nut-server service is started but it benignly succeeds > without starting upsd becaue MODE is set to netclient in > /etc/nut/nut.conf. The nut-driver service failure causes systemd to > that the system is in a degraded state because the unnecessary > nut-driver.service failed to start. > > Ideally, upsmon should create the /run/nut directory if needed so the > nut-server package doesn't not need to be installed. Alternatively, > the nut-driver service should succeed benignly when not needed in the > same way the nut-server service does. This is quite weird, the package already contains a systemd tmpfiles snippet (/usr/lib/tmpfiles.d/nut-client.conf) that should create the directory during the boot. Could you please give me the output of "systemctl list-dependencies nut-monitor.service" and "systemctl list-dependencies --after nut-monitor.service" ? Kind regards, Laurent Bigonville
Bug#961474: nut-client can't be run without nut-server installed
Package: nut-client Version: 2.7.4-12 Severity: important Dear Maintainer, I have two systems connected to a single UPS. The first system running both nut-server and nut-client packages works fine. The second system running only nut-client experiences this problem. Systemd can't sucessfully start the nut-monitor.service. The reason is that the /run/nut directory does not exist for upsmon to write its pid file. Even though upsmon starts and connects to the remote server, systemd eventually kills it becuase the pid file never gets written. The undesirable work around is to install the nut-server package so that something run by it creates /run/nut before upsmon is run. This also results in systemd attempting and failing to start the nut-driver service. The nut-server service is started but it benignly succeeds without starting upsd becaue MODE is set to netclient in /etc/nut/nut.conf. The nut-driver service failure causes systemd to that the system is in a degraded state because the unnecessary nut-driver.service failed to start. Ideally, upsmon should create the /run/nut directory if needed so the nut-server package doesn't not need to be installed. Alternatively, the nut-driver service should succeed benignly when not needed in the same way the nut-server service does. David Engel da...@istwok.net *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (100, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages nut-client depends on: ii adduser 3.118 ii init-system-helpers 1.57 ii libc62.30-8 ii libupsclient42.7.4-12 ii lsb-base 11.1.0 Versions of packages nut-client recommends: ii bash-completion 1:2.10-1 Versions of packages nut-client suggests: pn nut-monitor -- Configuration Files: /etc/nut/nut.conf [Errno 13] Permission denied: '/etc/nut/nut.conf' /etc/nut/upsmon.conf [Errno 13] Permission denied: '/etc/nut/upsmon.conf' /etc/nut/upssched.conf [Errno 13] Permission denied: '/etc/nut/upssched.conf' -- no debconf information
