Automatic reset of /dev/shm/ols permissions

Napsty

Napsty

New Member
#1
#1
Hello folks,

We're monitoring the OLS setups by frequently parsing the .rtreport files located in /dev/shm/ols/status.
Initially the permissions on /dev/shm/ols are set to 750 with owner and group set to the ones defined in the OLS config (httpd_config).

We've changed the permissions so that our monitoring service (running as another user) is able to read these files.
However we noticed that these permissions get reset, pretty much 24h after the last OLS service restart (lsws).
Can the needed permissions be configured anywhere? I haven't found anything related to rtreport or status file permissions in the docs.

Thanks :)
 
Napsty

Napsty

New Member
#3
#3
I see that this is triggered automatically when the QUIC.cloud whitelist was changed:

Code: 
2025-03-05 09:38:27.029847 [INFO] [1499525] Daily download QUIC.cloud whitelist IP to tmp/download-quic-cloud-ips ...
2025-03-05 09:38:27.661524 [NOTICE] [1499525] QUIC.cloud IP list has been changed, request  a graceful restart.
2025-03-05 09:38:27.802188 [NOTICE] [1499523] Child Process:1499525 request a graceful server restart: 2 ...
What is the exact command behind the graceful restart? Is this an internal function inside OLS? Because I can't see the lsws systemd service to be triggered at that time.
 
LiteCache

LiteCache

Active Member
#4
#4
Napsty said:
Hello folks,

We're monitoring the OLS setups by frequently parsing the .rtreport files located in /dev/shm/ols/status.
Initially the permissions on /dev/shm/ols are set to 750 with owner and group set to the ones defined in the OLS config (httpd_config).

We've changed the permissions so that our monitoring service (running as another user) is able to read these files.
However we noticed that these permissions get reset, pretty much 24h after the last OLS service restart (lsws).
Can the needed permissions be configured anywhere? I haven't found anything related to rtreport or status file permissions in the docs.

Thanks :)
Click to expand...
I'm not sure if you know what you're doing. From your description, you're trying to check whether OLS is running or not. The idea isn't bad, but in reality you're sitting on a branch (OLS) and you want to check whether the branch (OLS) is still attached to the trunk (your server). If the trunk (your server) is dead, you can't use the broken branch (OLS) to check whether the trunk (your server) is dead.

If you want to make sure that your website is still alive, i.e. connectable, you need an external service that regularly checks the connectivity of your site.
 
Napsty

Napsty

New Member
#5
#5
> I'm not sure if you know what you're doing.

:ROFLMAO:

Our monitoring reads the .rtreport files from /dev/shm/ols. But the permissions of /dev/shm/ols always gets reset to a default permission (0750), where only the user and group, under which OLS is running, is able to access these files within that path.
 
Last edited:
LiteCache

LiteCache

Active Member
#6
#6
Napsty said:
> I'm not sure if you know what you're doing.
Our monitoring reads the .rtreport files from /dev/shm/ols. But the ownership of /dev/shm/ols always gets reset to a default permission, where only the user, under which OLS is running, is able to access these files within that path.
Click to expand...
And what is it supposed to check?

It would be helpful if you could enrich us with your inexhaustible knowledge so that we can understand your intention. At the moment and based on your previous descriptions, the meaning and purpose of your plan is unclear.
 
Napsty

Napsty

New Member
#7
#7
The .rtreport files obviously contain the access statistics of OLS (https://docs.litespeedtech.com/lsws/realtime/#through-rtreport-files). Our monitoring reads these files to generate aggregated statistics and creates graphs from it, etc.
Our monitoring services and scripts don't run as root (for security purposes), hence they can't access anything inside /dev/shm/ols.
We can temporarily adjust the permissions of /dev/shm/ols, but they get reset every once in a while by internal graceful restarts of OLS.

Edit: I guess what I'm trying to say or ask here: Would it be possible to either
- Change the hard-coded permission from 0750 to 0755
or
- Make the permissions of directory /dev/shm/ols configurable
 
LiteCache

LiteCache

Active Member
#8
#8
Napsty said:
Our monitoring reads these files to generate aggregated statistics and creates graphs from it, etc.
Click to expand...
Please allow me to question this need. What exactly triggers this monitoring tool? The load, the requests or something else?

Please forgive me for questioning, but your request could perhaps be solved much more easily.
 
Napsty

Napsty

New Member
#9
#9
First of all thank you for responding and getting into this topic with me. (y)

It's just a script, running in a specific interval (1min for example) reading the .rtreports stats. Doesn't matter the load or anything else. It gives us an idea of how many connections OLS receives. Similar to Apache's server-status or Nginx's stub status.

> your request could perhaps be solved much more easily

I see that another possibility would be to use curl to access the stats on the admin port 7080, but that would require a rewrite of our scripts.

It's doable, but changing the default permissions of /dev/shm/ols is certainly also doable. Especially since I don't see a security benefit of disallowing anyone to read files inside /dev/shm/ols. Maybe there are security reasons behind hard-coding the permission to 0750, but I could not spot anything relevant inside /dev/shm/ols to protect from being read. :unsure:
 
LiteCache

LiteCache

Active Member
#10
#10
I don't think that OLS support can give you the relevant information. The support in this forum is good, but this forum is not a developer forum where you can question every line of code. Please remember that OLS is provided free of charge. Therefore, you have to be flexible for your requirements and tolerate alternative solutions. If checking the running processes or requests is not time-critical, then simply use the access_log. All other requests cannot be recorded with any web server anyway. Neither with Apache nor nginx.
 
You must log in or register to reply here.
Top