Power off don't work

mlillo · March 16, 2022, 10:18pm

Hi everyone,

I’m new to rockstor, I came from using openmediavault but I decided to use Rockstor because of the support for btrfs. But now I’m having the problem that I can’t shutdown the system because shutting down restarts it.

can anybody help me?

Thanks so much

Hooverdan · March 17, 2022, 3:43am

@mlillo Welcome to the Rockstor community
Can you give some more information about your setup?
Which version of Rockstor are you running?
What motherboard/CPU combo are you running?

mlillo · March 17, 2022, 10:34pm

Hi @Hooverdan,

thanks for answering so fast.
System information:

Rockstor 4.1.0-0
Linux NAS 5.3.18-150300.59.54-default #1 SMP Sat Mar 5 10:00:50 UTC 2022 (1d0fa95) x86_64 x86_64 x86_64 GNU/Linux
Motherboard: Asrock J3455

lscpu

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 39 bits physical, 48 bits virtual
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 92
Model name: Intel(R) Celeron(R) CPU J3455 @ 1.50GHz
Stepping: 9
CPU MHz: 2288.009
CPU max MHz: 2300,0000
CPU min MHz: 800,0000
BogoMIPS: 2995.20
Virtualization: VT-x
L1d cache: 96 KiB
L1i cache: 128 KiB
L2 cache: 2 MiB
NUMA node0 CPU(s): 0-3
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Retpolines, IBPB conditional, IBRS_FW, STIBP disabled, RSB filling
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse
sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xt
opology tsc_reliable nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl v
mx est tm2 ssse3 sdbg cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave rd
rand lahf_lm 3dnowprefetch cpuid_fault cat_l2 ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ep
t_ad fsgsbase tsc_adjust smep erms mpx rdt_a rdseed smap clflushopt intel_pt sha_ni xsaveopt xsavec xg
etbv1 xsaves dtherm ida arat pln pts arch_capabilities

The only thing I have modified in the system are two systemd services:

I added this service as it said here for WOL to work:

NAS:/etc/systemd/system # cat WOL-eth0.service
[Unit]
Description=Wake-on-LAN for eth0
Requires=network.target
After=network.target
[Service]
ExecStart=/usr/sbin/ethtool -s eth0 wol g
Type=oneshot
[Install]
WantedBy=multi-user.target

I added the option of TimeoutStopSec=480 on docker.service because it had rock-ons that with corrupted data when shutting down the system. I already had this configuration in my previous NAS operating system. These problems occurred mainly with jellyfin

NAS:/etc/systemd/system # cat docker.service
[Unit]
Description=Docker Application Container Engine
Documentation=http://docs.docker.com
After=network.target lvm2-monitor.service SuSEfirewall2.service rockstor-bootstrap.service

[Service]
EnvironmentFile=/etc/sysconfig/docker

# While Docker has support for socket activation (-H fd://), this is not
# enabled by default because enabling socket activation means that on boot your
# containers won’t start until someone tries to administer the Docker daemon.
Type=notify
NotifyAccess=all
ExecStart=/usr/bin/dockerd --add-runtime oci=/usr/sbin/docker-runc $DOCKER_NETWORK_OPTIONS $DOCKER_OPTS --config-file /opt/rockstor/conf/docker-daemon.json
ExecReload=/bin/kill -s HUP $MAINPID
TimeoutStopSec=480

# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=1048576
LimitNPROC=infinity
LimitCORE=infinity

# Uncomment TasksMax if your systemd version supports it.
# Only systemd 226 and above support this property.
TasksMax=infinity

# Set delegate yes so that systemd does not reset the cgroups of docker containers
# Only systemd 218 and above support this property.
Delegate=yes

# Kill only the docker process, not all processes in the cgroup.
KillMode=process

# Restart the docker process if it exits prematurely.
Restart=on-failure
StartLimitBurst=3
StartLimitInterval=60s

[Install]
WantedBy=multi-user.target

Thanks so much for your help
`

Hooverdan · March 17, 2022, 11:40pm

@mlillo before you added the WOL enablement (assuming it’s also set in the BIOS under the ACPI Management tab), did they system show that restart-instead-of-shutdown behavior?

I did come across some articles that talked about this problem and being related to WOL setup, so the system essentially wakes itself up, even without external input. The fix for that was to add a kernel parameter as described here:

https://wiki.archlinux.org/title/Wake-on-LAN#Wake-up_after_shutdown

or mentioned in this thread:
https://bbs.archlinux.org/viewtopic.php?id=260440

in the BIOS you can also turn off some of the waking options via USB keyboard or USB mouse, and only restrict it to a pci-e device (i.e. using WOL). Have you tried those settings as well (assuming you run Rockstor as a headless server without the need to wake it up with a connected keyboard or mouse)?

The guy behind this link I think spent an extensive amount of time trying to track down his “wake-up” issues, there might be some additional insights why this could be occurring:

gist.github.com

https://gist.github.com/george-hawkins/a897a6fe116093a4c1f29ad19df088de

wake-issue.md

Diagnosing spurious wakes
========================

This gist documents my attempts to get to the bottom of spurious wakes after installing Ubuntu 20.04 LTS on my system.

Initially, I thought it might be another system on my network sending [Wake-on-LAN (WoL)](https://en.wikipedia.org/wiki/Wake-on-LAN) packets. Then I thought it might be a known XHCI spurious wake kernel issue. And lastly, I finally resolved things by actively disabling the ability of USB devices, e.g. the mouse, to wake the system.

**Update:** I later came up with a better way of disabling wake-on-mouse that's covered [here](https://github.com/george-hawkins/wake-on-mouse).

Note: as one of these steps, I upgraded the system BIOS - while this didn't resolve this particular issue, it did resolve an annoying issue with the graphic state not being properly restored for certain applications after wake-up.

This file has been truncated. show original

Or somebody else on this friendly forum has experienced this problem and has some better advice

mlillo · March 18, 2022, 7:03am

@Hooverdan,

I understand what you are saying and I saw several articles regarding this but in my case it has been working and suddenly it has stopped working and I think the only difference since then is the updates of the system itself.

Also, that WOL service I added, I have disabled it and the behavior is still the same.

The truth is that it is very rare. Thanks so much

mlillo · March 18, 2022, 9:52pm

In the end it seems that it was the wol service. I have deactivated it and it turns off correctly but I have run out of wake on lan.
I don’t quite understand why it worked and now it doesn’t.
I have also created an issue in the project with my idea of adding this feature that I understand is essential in a NAS for home use. or at least for me it is.

mlillo · March 21, 2022, 10:14pm

In the end I managed to fix it by creating the following line in the root user’s crontab:

# crontab -l 
@reboot /usr/sbin/ethtool -s eth0 wol g

Hooverdan · March 21, 2022, 10:57pm

so, for my own education, this works as well, when you have a normal shutdown/startup scenario as opposed to running a reboot on the server?

Glad you found a working solution.

mlillo · March 21, 2022, 11:33pm

Yes this works well.
You can shutdown the system and weak up this by wol. No problem.