Hi all - pretty new here so please be patient with me.
After an install of “Rockstor-Leap15.5-RaspberryPi4.aarch64-5.0.9-0.raw” on Raspberry pi4 8GB ram, could not access the Rockstor web-UI.
Upon running “systemctl status rockstor.service” this is what I get:
ROCKSTORY:~ # systemctl status rockstor.service
○ rockstor.service - Rockstor startup script
Loaded: loaded (/usr/lib/systemd/system/rockstor.service; enabled; vendor preset: disabled)
Active: inactive (dead)
Jan 08 12:00:19 ROCKSTORY systemd[1]: Dependency failed for Rockstor startup script.
Jan 08 12:00:19 ROCKSTORY systemd[1]: rockstor.service: Job rockstor.service/start failed with result ‘dependency’.
Then when I run: systemctl restart rockstor.service
After a minute or two the terminal prompt re-appears. The I run: systemctl status rockstor.service
I get
ROCKSTORY:~ # systemctl status rockstor.service
● rockstor.service - Rockstor startup script
Loaded: loaded (/usr/lib/systemd/system/rockstor.service; enabled; vendor preset: disabled)
Active: active (running) since Sat 2024-06-29 09:02:56 BST; 22min ago
Main PID: 24753 (supervisord)
Tasks: 11
CGroup: /system.slice/rockstor.service
├─ 24753 /opt/rockstor/.venv/bin/python /opt/rockstor/.venv/bin/supervisord -c /opt/rockstor/etc/super>
├─ 24757 /opt/rockstor/.venv/bin/python /opt/rockstor/.venv/bin/gunicorn --config ./conf/gunicorn.conf>
├─ 24758 /opt/rockstor/.venv/bin/python /opt/rockstor/.venv/bin/data-collector
├─ 24759 /opt/rockstor/.venv/bin/python /opt/rockstor/.venv/bin/django-admin run_huey --workers 2 --wo>
└─ 24760 /opt/rockstor/.venv/bin/python /opt/rockstor/.venv/bin/gunicorn --config ./conf/gunicorn.conf>
Jun 29 09:02:56 ROCKSTORY systemd[1]: Started Rockstor startup script.
Jun 29 09:02:58 ROCKSTORY poetry[24753]: 2024-06-29 09:02:58,717 INFO Set uid to user 0 succeeded
Jun 29 09:02:58 ROCKSTORY poetry[24753]: 2024-06-29 09:02:58,731 INFO RPC interface ‘supervisor’ initialized
Jun 29 09:02:58 ROCKSTORY poetry[24753]: 2024-06-29 09:02:58,732 INFO supervisord started with pid 24753
Jun 29 09:02:59 ROCKSTORY poetry[24753]: 2024-06-29 09:02:59,740 INFO spawned: ‘gunicorn’ with pid 24757
Jun 29 09:02:59 ROCKSTORY poetry[24753]: 2024-06-29 09:02:59,766 INFO spawned: ‘data-collector’ with pid 24758
Jun 29 09:02:59 ROCKSTORY poetry[24753]: 2024-06-29 09:02:59,772 INFO spawned: ‘ztask-daemon’ with pid 24759
Jun 29 09:03:01 ROCKSTORY poetry[24753]: 2024-06-29 09:03:01,777 INFO success: data-collector entered RUNNING state>
Jun 29 09:03:04 ROCKSTORY poetry[24753]: 2024-06-29 09:03:04,781 INFO success: gunicorn entered RUNNING state, proc>
Jun 29 09:03:09 ROCKSTORY poetry[24753]: 2024-06-29 09:03:09,789 INFO success: ztask-daemon entered RUNNING state, >
…
All seems okay and most importantly I am now able to access the web-UI.
Please has any one come across this issue. Its a bit of a pain as each time I reboot - I have to check the status of Rockstor and then run: systemctl restart rockstor.service.
@MyOwn Just a quick update on the referenced issue concerning this report, and the known Pi4 reboot issue referenced on the Downloads page:
We now have a pending fix for this, as yet unreleased, by way of the following pull request:
This fix (to rockstor-pre.service) is expected to be included in 5.0.14-0 rpm (testing channel). But given we have a little more work to do before that release, you may fancy applying the equivalent fix, but by-hand, to your own install (if familiar with CLI and nano). The referenced issue has a comment on how to do this:
I have noticed this behavior on a recent VM I built (x86_64 flavor though). Every time booting up, it starts with that wait failure and I have to manually execute the pre and main Rockstor service. It might be because it goes through a virtualized adapter that just takes longer to connect or something else. I will try that fix manually as well.
Update: Yah, that’s not it for the VM scenario. I will investigate further and open a separate thread if it continues that way.
In your case, given you mentioned the network adapter, I would recommend you to look into the network-wait-online systemd service (or similar name, sorry I can’t remember exactly). I have had a bare metal Leap install doing that a while ago as my bridge adapter was somehow taking some time to get a DHCP lease, causing that systemd service to time out after 90 sec.
I don’t think it’s related to the same timeout described by @phillxnet on the Pi4.
phillxnet