TerraSync Client - Sync start, and Log Localization Issue

[Chief]

I have figured out this much: I was not using the correct command line to run `service`.
Eventually I found that navigating into any of those directories where `service` is located, will work if I use `./service nginx stop` or `./service nginx start`.

Thing is, that still doesn't fix the problem of the browser only showing only the "Loading..., please wait!" screen.

Is there a chance this is because `nginx` itself isn't in any of the paths where `service` can be found?

If it matters and/or helps, here is the output of `env` via ssh. Please note that the `X11` directory in the last two paths, does not exist in either of them:

Code: Select all

PATH=/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/bin/X11:/usr/bin/X11

[TMSupport]

Please refer to the article for troubleshooting.

[Chief]

I don't see direct evidence of a filesystem failure.

What does the information below tell you?

Summary of error/ERROR from dmesg:

Code: Select all

[    1.215758] i915 0000:00:02.0: Direct firmware load for i915/bxt_dmc_ver1_07.bin failed with error -2
[    1.296307] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[    1.740994] ***ERROR***: PR file name /var/lib/scst/pr/1:0:0:0 parent directory doesn't exist
[    1.754168] ***ERROR***: PR file name /var/lib/scst/pr/2:0:0:0 parent directory doesn't exist
[    1.758012] ***ERROR***: PR file name /var/lib/scst/pr/3:0:0:0 parent directory doesn't exist
[    2.258852] ***ERROR***: PR file name /var/lib/scst/pr/4:0:0:0 parent directory doesn't exist
[    2.265356] ***ERROR***: PR file name /var/lib/scst/pr/5:0:0:0 parent directory doesn't exist
[    2.760700] ***ERROR***: PR file name /var/lib/scst/pr/7:0:0:0 parent directory doesn't exist
[   11.757405] r8169 0000:02:00.0: Direct firmware load for rtl_nic/rtl8168e-3.fw failed with error -2
[   13.853499] r8169 0000:01:00.0: Direct firmware load for rtl_nic/rtl8168e-3.fw failed with error -2
[   41.500901] ***ERROR***: SCST device for SCSI device 7:0:0:0 not found

Summary of ext-4 related messages from dmesg:

Code: Select all

[    3.556091] EXT4-fs (md9): mounted filesystem with writeback data mode. Opts: commit=60,data=writeback
[    9.704687] md: recovery of RAID array md9
[    9.803093] md: md9: recovery interrupted.
[    9.877779] md: recovery of RAID array md9
[   10.003728] md: md9: recovery interrupted.
[   10.104542] md: recovery of RAID array md9
[   10.219532] md: md9: recovery interrupted.
[   10.309829] md: recovery of RAID array md9
[   10.479724] EXT4-fs (md9): re-mounted. Opts: (null)

[Chief]

Also, this warning:

Code: Select all

[    1.227221] dev_vdisk: ***WARNING***: Unable to find /var/lib/scst/vdev_mode_pages (err -2), saved mode pages disabled. You should create this directory manually or reinstall SCST

[Chief]

I guess never mind on this, for now.

None of the instructions provided for restarting nginx via ssh worked. At least when running TOS 5, those instructions did not work for me.
The `service` command could not be found from command line, either on the F5-221 that was acting up, or on the one that is completely working.

There was no evidence of any corruption on the array, and all files were available via the network, via samba.
Eventually I just used Windows Explorer and copied all the files from the NAS that had no browser UI, to the one that does have a browser UI.

After that, I shut down the one with a broken browser UI, pulled all the drives, started it again, and could access the startup pages in the browser again. At that point I just re-installed the latest TOS 5. The drives, array, and volume all checked out fine with no errors or signs of corruption.

Figured then that I might as well blow out the old volume and array, and set it up for TRAID. Again, all drives checked out fine, and the new array and volume were created with other issues. The array was synchronized overnight. I will manually copy everything from the new NAS back to the old one, so everything is backed up at least as of today.

I cannot say for sure that TerraSync Server or Client was directly responsible for the browser GUI getting blown up on the one NAS, but they definitely were not working well and it's difficult to put any trust in them as they are now.

Seems best to wait until TerraSync is more mature, out of Beta, and has working Windows/Android clients before touching it again.