rock-on service ON state not surviving reboot

[phillxnet]

It seem that in 3.8-2 my Rock-on service is defaulting to OFF when I shut down with it ON.

I have confirmed this on a VM and real hardware.

Is this also related to #660 I don't see an entry in /opt/rockstor/etc/supervisord.conf for rock-ons.

Still working out what does what and why I'm afraid.

[phillxnet]

Confirmed as unchanged in 3.8-3 (upgraded from 3.8-2) only tested in vm on this version as of yet though.

[devonwarren]

This issue is happening for me as well, according to the journalctl it's because the docker root is not mounted by the time it tries to start. The docker service needs to be started after the mounts are made.

Jul 22 15:23:12 rockstor docker-wrapper[2293]: Docker root(/mnt2/Addons) not mounted.

[schakrava]

@devonwarren @phillxnet Thanks for your comments. So this is more of a feature than a bug at this point. What I mean by is it's this way because the proper way of doing this involves more knowledge about systemd and mounting that share properly than I currently have. If you know systemd well, you could look into the startup scripts and help fix this faster.

the wrapper script is located in src/rockstor/scripts/docker_wrapper.py and the docker startup scripts are in /etc/systemd/system/docker.* As part of the rockstor service startup, the rock-on root share is mounted, but i don't know how to make docker wait for it or properly mount the share in docker_wrapper. I tried the obvious methods and they din't work at the time of implementation.

I'll eventually get to it, but just thought I'd share this in case you want to contribute.

[phillxnet]

This issue has recently been mentioned in a forum thread so linking to that thread so that it might be updated with progress or visa versa:-
http://forum.rockstor.com/t/rock-ons-plex-rock-on-turned-off-after-shutdown/310

@schakrava I had a quick look myself and all I can come up with is a systemd managed automount on request rockon-root but this presumably is in the obvious methods category and no I haven't yet managed to try this out. Nor am I familiar with systemd managed mount points but I know it's possible and as you say seems like the way to go. I can have a go at this again soon once I get some other things done and dusted though. What have you tried so far re systemd auto mounts?

[phillxnet]

These links are as far as I got with this a while ago:-

https://www.happyassassin.net/2011/05/12/cute-systemd-trick-of-the-day-auto-mounting-remote-shares/

“But to make it super awesome, add two options: ‘noauto comment=systemd.automount’ . Then what happens is the share gets mounted as soon as something tries to access it…but not before. So boot runs as fast as possible, and as soon as you actually try to access the share, it gets mounted. Thanks, systemd!”

http://www.freedesktop.org/software/systemd/man/systemd.automount.html
systemd.automount
which in turn accesses the systemd.mount

https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files
"
.mount: This unit defines a mountpoint on the system to be managed by systemd. These are named after the mount path, with slashes changed to dashes. Entries within /etc/fstab can have units created automatically.
.automount: An .automount unit configures a mountpoint that will be automatically mounted. These must be named after the mount point they refer to and must have a matching .mount unit to define the specifics of the mount."

[phillxnet]

I am having another look at this currently.

[phillxnet]

Closing as fixed by above referenced @schakrava pull request #808 now merged into testing.
Tested in testing 3.8.5-12 on VM and slow real hw (both with 4.1.0 kernel though); result was that rock-ons service maintained enabled status over multiple reboots once enabled.