On Wed, 28 Oct 2015, George Anchev wrote:
Beautiful! The shutdown succeeded.
Did you see a line in the journal similar to this ?
Oct 06 22:49:54 pinta nut-delayed-ups-shutdown[1854]:
nut-delayed-ups-shudown.service calling
upsdrvctl to shut down UPS unit
However there was no any notification on desktop at
I'm guessing you use KDE and this may be a problem in the default way KDE
treats the output of the "wall" program. I don't have a KDE setup to test
with, but try looking at KDE's System settings -> Common appearance and
Behaviour -> Applications and System notifications -> Manage notifications
to find out what is happening.
It may also be something in your mesg y/n setting. What does "mesg"
report?
One thing that caught my attention: I have disabled the
nut-delayed-ups-shutdown service one day ago (many reboots since then)
in order to avoid the effect of the UPS self-shutting on normal reboot.
After this last test right now, and after the system shut down
completely I plugged the cord in and booted. However during the boot
process the UPS powered off while the power was on and the boot was not
yet complete (argh...). Then in a second or two, without me doing
anything, the UPS got back ON and I started the computer - this time the
boot was clean, without power off.
It seems this solves the problem to have a clean reboot without UPS
powering off. However it looks like a misbehavior after all because the
UPS is not supposed to shutdown if the nut-delayed-ups-shutdown service
is disabled, right? Or is anything else shutting down the UPS itself?
Its systemd trying to "help" you. OpenSUSE 13.2 includes a delayed UPS
shutdown script in /usr/lib/systemd/system-shutdown/nutshutdown . I
suggest you comment out the command in that script.
Another thing (a bit of a side question, I hope it is ok to ask): During
the last 3-4 months (using simply KNotify about UPS connection states) I
noticed that sometimes unpredictably a notification appears that the USB
connection to the UPS is lost and a few seconds later another
notification appears that the connection is restored. And this repeats
to infinity. The only way to get out of it is to shutdown the machine,
turn off the UPS, unplug the power and restart everything again. I had
no luck finding a pattern when and why it happens. This has never
happened before. The batteries are fairly new (changed late January
2015) and there have been no power outages since then (maybe one or two
for 2-3 minutes only). However I notice that a short power off test
(like the one I just did) makes the battery fall from 100% to 85% for
less than a minute and then charges very long to reach 100% again. A
friend said he has noticed similar peculiarity with other MGE UPS units.
Can you share thoughts on this? I hope you don't mind me asking.
Endless repetitions of (Communication lost - Communication
re-established): its been reported before in this mailing list for various
drivers, and others may know what causes it. I suggest opening a new
issue in this mailing list with a specific technical description.
Roger
_______________________________________________
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
