1)

1) I would like an auto-reminder email to be sent to the person responsible for an overdue ticket, which I /think/ is what the included Indicator #1 "respect of planned due date/time" on element "ticket" does (or at least would do if I ticked the appropriate Mail Receivers).
What I'm less clear about is whether Projeqtor's Cron function needs to be running in order to generate these Indicator emails,

YES !

or whether Projeqtor uses a similar mechanism to Wordpress where a lightweight cron routine is called on each page request but only does work if more than a preset time has elapsed since the last work cycle

No, as this mecanism would require that at least one user interacts with the application.

ProjeQtOr uses internal Cron system (a dedicated php process) that is able to send reminders (and execute other Cronned tasks such as global planning) even if no user is connected (in the middle of the night)

2)

Normally when I look in Administration section the cron status is "stopped". If I press Run it stays running for about 20 minutes before php-fpm kills it and logs the message "script '/path/to/projeqtor/tool/cronRun.php' (request: "GET /projeqtor/tool/cronRun.php") execution timed out (1104.798923 sec), terminating". That's no surprise of course - the server's php.ini has max_execution_time = 60 seconds.

Projeqtor Cron tries and change max_execution_time at run time so that Cron never stops.
This won't be possible if safe_mode is enabled. Just disable safe_mode to fix the issue.
Note that safe_mode is not recommended (even if largely user by hosting providers), it is obsolete on PHP 5.3 and has been removed in PHP 5.4

Is there any way to automatically restart Projeqtor's cron process? For instance by using Linux system cron to wget a url or execute a local CLI file?

Any new connection to the application will automatically restart the Cron.
(this is usefull if you stop PHP for maintenance)

Projeqtor Cron tries and change max_execution_time at run time so that Cron never stops.
This won't be possible if safe_mode is enabled. Just disable safe_mode to fix the issue.
Note that safe_mode is not recommended (even if largely user by hosting providers), it is obsolete on PHP 5.3 and has been removed in PHP 5.4

I have Projeqtor running in PHP 7.3.8 on an up to date Fedora Linux server... there is no safe_mode setting in php.ini and, as you say, it would not be honoured now in any case. But something is definitely killing the cron process and preventing it from auto-restarting. Here's what I've tried to do:
.

1. Log into Projeqtor as an administrator
2. Check Projeqtor's Administration page - Cron is stopped
3. Press the run button. Projeqtor now says:

   cron status : 
   	running
      General cron sleep time = 10 seconds
      Alert generation cron delay = 30 seconds
      Automatic import cron delay = 60 seconds
   disabled
      Notifications
      Leave rights earned
      Send grouped emails
      Email input
   

4. There are no relevant entries in /var/log/php-fpm/error.log but [...]/files/logs/projeqtor_20190812.log has entry:

   2019-08-12 20:15:20.710 ===== TRACE ===== Cron started at 12/08/2019 20:15:20

5. 30 minutes later refresh Projeqtor's Administration page - Cron is stopped
6. There are no relevant entries in [...]/files/logs/projeqtor_20190812.log but /var/log/php-fpm/error.log has entries:

   [12-Aug-2019 20:35:12] WARNING: [pool www] child 14410, script '/path/to/projects/tool/cronRun.php' (request:"GET /projects/tool/cronRun.php") execution timed out (1192.154278 sec), terminating
   [12-Aug-2019 20:35:12] WARNING: [pool www] child 14410 exited on signal 15 (SIGTERM) after 1482.057330 seconds from start
   [12-Aug-2019 20:35:12] NOTICE: [pool www] child 22635 started

7. Disconnect Projeqtor and log back in via SSO then check Administration page - Cron is stopped
8. Open a different make of browser, go to Projeqtor and log in as a local (non-SSO) user then check Administration page - Cron is stopped

Do you have any suggestions as to what might be causing this? Are there any other PHP / PHP-FPM settings that have an effect here? Is there a more verbose log setting in Projeqtor that might reveal more?

Is there any way to automatically restart Projeqtor's cron process? For instance by using Linux system cron to wget a url or execute a local CLI file?

Any new connection to the application will automatically restart the Cron.
(this is usefull if you stop PHP for maintenance)

Assuming I can get this auto-restart to work, it still relies on a user actively logging into Projeqtor should either the cron process die or php-fpm is restarted. That's fine for busy projects with many users, but for light usage an admin has to babysit Projeqtor on a regular basis (even just to logon/logoff again) in order to ensure cron is running. This strikes me as a bit fragile for what is otherwise a super robust piece of software.

My suggestion for the longer-term would be to come up with a way for a Linux cron job to tickle Projeqtor periodically to ensure its internal cron process really is running all the time. One way would be to create a zero-privileged user (maybe with an auto-logoff upon successful login) and have some way of logging it on to Projeqtor with no human interaction, eg by accessing a "cron-restart.php" url via curl or wget.

I have set "$logLevel='7';" and "$paramDebugMode='true';" in files/config/parameters.php , so here is some additional information about my cron problem. In all these tests I have left my main browser (Firefox) open with an SSO-user that has administration rights continuously logged in. I also had a different make of browser (MS Edge) open and used that for logging in & out a non-SSO user that has administration rights (actually the inbuilt user #1) as a test to see if it restarted the dead cron process.

Pressing the cron run button on the Administration page generates log entries::

2019-08-13 00:38:45.969 ..... SCRIPT .... [IP redacted] =====/projects/tool/cronRun.php
2019-08-13 00:38:45.979 ..... SCRIPT .... [IP redacted] Page=cronRun.php
2019-08-13 00:38:45.979 ..... SCRIPT .... [IP redacted] refreshParameters()
2019-08-13 00:38:45.987 ..... SCRIPT .... [IP redacted] getProfile(objectOrIdProject=Audit #62)
2019-08-13 00:38:45.987 ..... SCRIPT .... [IP redacted] getProfile(objectOrIdProject=Audit #62)
2019-08-13 00:38:46.011 ===== TRACE ===== Cron started at 13/08/2019 00:38:46

There does not appear to be anything logged when the process is killed approx 20mins later. files/cron/RUNNING continues to exist, in this case with a last modified time of 00:55:06.

Logging in as a non-SSO user from the other make of browser generates log entries:

2019-08-13 02:13:48.513 ..... SCRIPT .... [IP redacted] Page=cronRelaunch.php
2019-08-13 02:13:48.514 ..... SCRIPT .... [IP redacted] refreshParameters()
2019-08-13 02:13:48.524 ..... SCRIPT .... [IP redacted] getProfile(objectOrIdProject=Audit #63)
2019-08-13 02:13:48.524 ..... SCRIPT .... [IP redacted] getProfile(objectOrIdProject=Audit #63)
2019-08-13 02:13:48.534 ===== TRACE ===== Cron started at 13/08/2019 02:13:48

files/cron/RUNNING get updated accordingly and the Administration page reports cron is running again.

Logging the non-SSO user out of the other browser and rebooting the server a short time later to apply a kernel patch does not remove files/cron/RUNNING but subsequently checking the Administration page does delete RUNNING. The page reports cron is stopped and there is nothing in the log file that refers to this or cron in general.

Logging in again from that other make of browser generates log entries:

2019-08-13 02:37:39.127 ..... SCRIPT .... [IP redacted] =====/projects/tool/cronRelaunch.php
2019-08-13 02:37:39.132 ..... SCRIPT .... [IP redacted] Page=cronRelaunch.php
2019-08-13 02:37:39.132 ..... SCRIPT .... [IP redacted] refreshParameters()
2019-08-13 02:37:39.141 ..... SCRIPT .... [IP redacted] getProfile(objectOrIdProject=Audit #65)
2019-08-13 02:37:39.142 ..... SCRIPT .... [IP redacted] getProfile(objectOrIdProject=Audit #65)

Note that there was no "===== TRACE ===== Cron started" entry at this point, and refreshing the Administration page reports cron as stopped.

Do you have any suggestions as to what might be causing this?

1) Check for disabled function in php.ini.set_time_limit must not be disabled.
2) Migrate to latest stable release (8.1.4)
We don't support issues on old versions through forum support.
Support opn old versions (not the current "last stable release") is possible only through our professional support service.

1) Check for disabled function in php.ini.set_time_limit must not be disabled.

Turns out the problem was caused by a global php-fpm option that kills a process after a given time irrespective of the max_execution_time option in php.ini - it was set to 900 seconds to deal with errant scripts. I have set the following in the pool definition file for this vhost under /etc/php-fpm.d/ (or in /etc/php-fpm.conf depending on your setup), but note that anyone encountering this on shared hosting is likely to be stuck because php-fpm pool definitions are generally not editable by hosting customers:

request_terminate_timeout = 0

Can this be included in the excellent list of requirements at https://sourceforge.net/p/projectorria/code/HEAD/tree/branches/V8.1/projeqtor/deploy/readme.txt ?

Also note that the cron process does not survive a "systemctl reload php-fpm", which has to be run every time a vhost pool is added / removed / changed. So for light use, particularly on servers where php-fpm restarts are outside the control of the Projeqtor administrator, the cron process is susceptible to dying without warning and won't restart until someone next logs in.

2) Migrate to latest stable release (8.1.4)

Done =)

Can this be included in the excellent list of requirements at sourceforge.net/p/projectorria/code/HEAD...or/deploy/readme.txt ?

Done for V8.2

Also note that the cron process does not survive a "systemctl reload php-fpm", which has to be run every time a vhost pool is added / removed / changed. So for light use, particularly on servers where php-fpm restarts are outside the control of the Projeqtor administrator, the cron process is susceptible to dying without warning and won't restart until someone next logs in.

We know this, that's why we set an auto-restart procedure for the cron, but cannot do this unles one script interacts with projeqtor.