Bug 8104 - License graphs assume crond is installed
Summary: License graphs assume crond is installed
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Server Installer (show other bugs)
Version: trunk
Hardware: PC Linux
: P2 Normal
Target Milestone: 4.18.0
Assignee: Alexander Zeijlon
URL:
Keywords: relnotes, tobfa_tester
Depends on:
Blocks:
 
Reported: 2023-02-21 12:23 CET by Alexander Zeijlon
Modified: 2024-11-27 07:55 CET (History)
1 user (show)

See Also:
Acceptance Criteria:
MUST: * Users (sysadmins) should be able to see license usage over time in tlwebadm. * License graph updates should not depend on having crontab installed. SHOULD: * The license graphs should update on regular intervals. COULD: * The stats should only be collected on systems where it is relevant.


Attachments
View of the Status->Licenses menu without crontab running the script. (32.64 KB, image/png)
2023-02-21 12:23 CET, Alexander Zeijlon
Details

Description Alexander Zeijlon cendio 2023-02-21 12:23:07 CET
Created attachment 1106 [details]
View of the Status->Licenses menu without crontab running the script.

During the installation of ThinLinc server, there is no check for if crontab is installed. We depend on crontab for updating the license usage graphs in Web Admin, since we use it for running the script tl-collect-licensestats.

Without the cronjob running, we get no graphs. See attachment.
Comment 1 Alexander Zeijlon cendio 2023-02-21 14:26:35 CET
The resulting error of not running the cronjob can be seen in /var/log/tlwebadm.log:
ERROR: opening '/var/opt/thinlinc/statistics/users-licenses.rrd': No such file or directory

The missing file users-licenses.rrd gets created by tl-collect-licensestats when it runs.
Comment 2 Alexander Zeijlon cendio 2024-11-18 13:18:25 CET
While crontab is not being deprecated in a strict sense, it looks like the more popular Linux distributions are moving away from it, in favor of more modern alternatives.

The fact that crontab isn't installed by default on e.g. Fedora 39 Workstation can be interpreted as a sign of this, and since we want to keep with the times, it is now also time for us to do the same move.
Comment 3 Alexander Zeijlon cendio 2024-11-18 13:33:04 CET
One alternative forward could be to add crontab and (or) anacron a requirement when installing the ThinLinc server. But, continuing on comment 2, we also want to keep our dependencies at a minimum. This, to not risk breaking compatibility with future releases of our supported Linux distributions.
Comment 4 Alexander Zeijlon cendio 2024-11-18 13:42:11 CET
Another alternative is to use Systemd timers.

It looks like it should be possible to use timers to achieve something that is equivalent to the crontab configuration that we are using today. But we will need to adjust our server install to set up the timer(s) we need, instead of just installing a cron-script to /etc.

We are also already depending on Systemd, since it is a requirement for running our services. Using timers would therefore not require us to add yet another dependency to the installation.
Comment 5 Alexander Zeijlon cendio 2024-11-18 13:55:46 CET
Let's use a Systemd timer. We should mimic the behavior of the cronjob that is currently used. its config line looks like this:
> */5 * * * * root <script name>
This translates to "run <script name> as the user root every 5 minutes", so this is the goal of the new timer.
Comment 6 Alexander Zeijlon cendio 2024-11-19 14:39:16 CET
The syntax "*/5" actually does not signify every 5 minutes, but instead it means that, in the case of minutes, the script will run when the (wall) clock is at some time modulo 5. So e.g. the script will run 12:00, 12:05, 12:10, 12:15 etc.

In a systemd timer this is equivalent to the directive:
> OnCalendar=*:0/5
This isn't necessarily what we want. We just want to make sure that the license graphs are updated every 5 minutes, it isn't important that the update occurs at a specific time.

Instead, we can use either of the two directives:
> OnUnitActiveSec=5m
> OnUnitInactiveSec=5m

OnUnitActiveSec sets activation time relative to the start of a previous event, while OnUnitInactiveSec sets activation time relative to the end of a previous event.

Since the script we are running to get updates runs quite fast, eihter one of these will likely work just fine.
Comment 7 Alexander Zeijlon cendio 2024-11-19 14:46:51 CET
I also noticed that since both OnUnitActiveSec and OnUnitInactiveSec are defined based on when their last trigger occured, we need to actually create an initial trigger for the timer sequence to start.

This can be done by adding one of the two directives:
> OnBootSec
> OnActiveSec

OnActiveSec will trigger an initial run of the corresponding service when the timer is first started.

OnBootSec will trigger an initial run at some specified time after the system booted, or directly if this time has already passed when the timer is started.
Comment 8 Alexander Zeijlon cendio 2024-11-20 12:51:35 CET
We have decided to use the OnCalendar directive, since this is closes to what the old cron job did.

It's also nice if the graphs generated have data points that are nicely placed on the graph grid, which seems to be aligned with hour timestamps.
Comment 13 Alexander Zeijlon cendio 2024-11-20 16:53:39 CET
The cron job we had for updating license stats has now been replaced with a Systemd timer that is running with equivalent scheduling, once every five minutes, starting at each hour.
> e.g. 10:00, 10:05, 10:10, 10:15... etc.
Comment 14 Alexander Zeijlon cendio 2024-11-20 17:14:04 CET
Testing:
========

I have installed the server and run tl-setup on RHEL9 and Ubuntu 24.04 in both master and agent configuration.

Master:
-------

The timer is enabled and runs every 5 minutes


Agent:
------

The timer is disabled.


Uninstall of server:
--------------------

The timer is removed regardless of server type.
Comment 15 Alexander Zeijlon cendio 2024-11-21 10:35:00 CET
Continuing on comment 14:
=========================

Upgrade:
--------

I also tested that the cron job is replaced by the timer when upgrading from 4.17.0
Comment 16 Alexander Zeijlon cendio 2024-11-21 10:51:03 CET
One thing that I should have mentioned earlier, is that the service, the timer triggers, is configured without an "Install" section/directive, hence making it a static service that can not be enabled on its own [1].

I looked at other timer-service pairs in /usr/lib/systemd/system, and this seems to be the preferred way of configuring such services.

It also makes sense for our use case, since the only purpose of the service is to be triggered by the timer in order for tl-collect-licensestats to run.

[1] See "man systemd.unit".
Comment 18 Alexander Zeijlon cendio 2024-11-21 12:16:39 CET
> MUST:
> * Users (sysadmins) should be able to see license usage over time in tlwebadm.
License graphs in tlwebadm are now updated by a Systemd timer instead of by a Cron job. So from a sysadmin's perspective, there will hopefully be no noticeable difference.

> * License graph updates should not depend on having crontab installed.
Now, they don't.

> SHOULD:
* The license graphs should update on regular intervals.
The scheduling remains the same as when we were using a Cron job. That is, <wall clock minute> mod 5 ⇾ e.g. 10:00, 10:05, 10:10 and so on.

> COULD:
> * The stats should only be collected on systems where it is relevant.
Since we are now installing a Systemd timer + service pair, we have the same level of control over it as we do with our other services. Hence, we are now only installing (enabling) and starting the timer on systems that run a ThinLinc-master node.
Comment 19 Alexander Zeijlon cendio 2024-11-22 10:06:47 CET
One additional note:

I considered writing an autotest for checking that the timer is actually started after running tl-setup. But since we are checking for calls to systemctl enable and systemctl start as a part of unit testing, this seemed a bit superfluous for now, even if it would be a good check to have.
Comment 20 Alexander Zeijlon cendio 2024-11-26 15:56:22 CET
Reopen after review-comments from Tobias.
Comment 23 Alexander Zeijlon cendio 2024-11-26 16:08:37 CET
Comments have been addressed. As a side effect of this, the installer now is a bit less verbose when writing to the installer log.
Comment 24 Tobias cendio 2024-11-27 07:50:44 CET
Tested server build #3838 on RHEL8, Ubuntu22.04, and SLES15.5.

The systemd timer and service for license usage graphs are properly installed and activated when installing the server as a Master. Conversely, the timer and service are inactive when the server is installed as an agent, although the systemd files are still put in place. This latter issue is likely difficult to work around and not a huge problem

It is evident through systemctl that the service is activated once roughly every 5 minutes, and the tlwebadm graphs are updated accordingly.

Upon uninstalling, the timer and service are inactivated and the files in question are properly removed for both agent and masters. Furthermore, upgrading from 4.17.0 results in removal of the crontab files.

Attempting to ’enable’ the service results in a warning message from systemctl explaining why this service lacking an install section cannot be enabled for various potential reasons. It is however affected by systemctl’s ’start’ command which simply runs the script once and then returns to its normal cycle. That does also seem to be the case if ran on an agent machine, which appears to suddenly put the service on the 5 minute cycle.
Comment 25 Tobias cendio 2024-11-27 07:55:13 CET
Acceptance criteria:

> MUST:
> Users (sysadmins) should be able to see license usage over time in tlwebadm.
✅ Confirmed -- the graphs are rendered as intended.
> License graph updates should not depend on having crontab installed.
✅ It doesn’t depend on crontab as we’re now using systemd timers instead.
> SHOULD:
> The license graphs should update on regular intervals.
✅ They update roughly every 5 minutes, like before.
> COULD:
> The stats should only be collected on systems where it is relevant.
✅ The service is triggered by default only for master servers.
Comment 26 Tobias cendio 2024-11-27 07:55:44 CET
Acceptance criteria are fulfilled and things appear to be working as intended.

Closing.

Note You need to log in before you can comment on or make changes to this bug.