error while loading shared libraries: libx265.so.165 on Centos about fits_web_ql

[skitaeff]

Resolved.

[jvo203]

Glad it has been resolved. If you are planning on running it on a server but accessing it from another computer (i.e. your laptop), there is a special option to make fits_web_ql listen on all network interfaces (not just the special localhost):

"an alternative network interface (only needed to make the local version run in a quasi-server mode)
cargo run --release -- --interface 0.0.0.0"

Then on your laptop you can point the web browser to http://your.server.ip.address:8080 to browse FITS files residing on the remote server. The port number can be changed too as per the README.

[skitaeff]

I'm getting the page that displays ALMA/HSC/NRO45M, and doesn't allow me just browse. What could be the reason?

[jvo203]

What is the full command you are using to run fits_web_ql (cargo run or cargo build)? Most likely your --features string contains a word "server". The "features" part should not contains any words "server". The "server" feature is reserved for use in the JVO environment. Normally the ALMA/HSC/NRO45M test page will be displayed if --features contains a server flag.

If you just run the vanilla "cargo run --release" and point your browser to http://localhost:8080 you should be seeing the correct file browser page. Then you can add extra options like --port, --interface or --home:

cargo run --release -- --port 8000 --interface 0.0.0.0 --home /a/path/to/your/FITS/files

[skitaeff]

Indeed, I was using --feature. Now it looks fine. Thanks.

BTW. On Centos, "cargo run" causes an attempt to rebuild everything. The check takes up to 2 mins delay in starting the server.

Instead, I'm run it directly

target/release/fits_web_ql --release -- --port 8080 --interface 0.0.0.0

I just want to check that this doesn't have any unintended consequences?

[jvo203]

It is perfectly OK to do a time consuming "cargo build --release" only once and then launch the server many times the way you do it (with optional parameters when needed). By the way, the port defaults to 8080 so unless you are planning to use a different port number, you do not need the port parameter.

With hindsight, regarding the --features section, in the future releases I will probably rename "server" to "jvo". This should make it less confusing for users from outside the JVO. Plus will also update the README file to make it clear that the "jvo" and other features are not meant for regular use. It is safe to use the "cdn" feature in order to reduce load on your fits_web_ql server. Then most of the boiler-plate static resources will be served from a nearby jsDelivr CDN server. You'd better test it with and without "cdn" to see which works better.

[jvo203]

By the way, the correct way of launching it after "cargo build --release" is:

target/release/fits_web_ql --port 8080 --interface 0.0.0.0

There is no longer a need for adding "--release --".

[skitaeff]

For whatever reason I can't get --home to work. It still goes to my personal home directory.

[jvo203]

There are a few things at play:

1. The FITSWebQL file viewer website remembers the last visited directory. Upon visiting http://localhost:8080 again it shows the last-visited directory, irrespective of the --home switch. Clicking on the "Home" link (the top-right part of the page) will bring you to the home directory (either specified by --home or the default $HOME).

2. Are you using the latest FITSWebQL version? The --home switch has been introduced only recently (5 days ago) in v4.1.5. If you have cloned from the master github repository, doing "git pull" from the fits_web_ql directory, and then "cargo update" from within the fits_web_ql directory will bring fits_web_ql and all the dependencies up to date. Or you can just download the latest release v4.1.5 and build from scratch.

Periodically doing "cargo update" does not harm, it will bring the related dependencies up to date.

[skitaeff]

Aha! This is the answer! I cloned 7 days ago.

[jvo203]

A hint how to speed up FITSWebQL when using SSDs. It it best to clone fits_web_ql onto a directory residing on the fastest storage medium you have (ideally NVME SSD). Inside fits_web_ql there is an internal FITSCACHE directory where the program caches half-float-converted FITS files (applicable only to bitpix = -32).

The first time a FITS file is accessed it will be read from its original location (ideally from a fast NVME SSD). The second time somebody accesses that same FITS file, fits_web_ql will read the FITS header from the original location and then proceed to load half-float binary cache from the FITSCACHE directory.

So even if your large FITS files reside on a fast SSD, if fits_web_ql itself is located on a slow HDD second-time loads of FITS files will appear slow compared with first-time accesses.