pelican.service in 4.9.1~ynh1 constant CPU usage and mem leak

[silverhook]

Describe the bug

After upgrading Pelican on YunoHost to 4.9.1~ynh1, I noticed that the new SysD pelican.service is running into errors and keeps running and consumes 100% of a CPU core an increasing amount of RAM.

What seems to be happening is that pelican --autoreload keeps running into some issues and keeps re-running ad infinitum for some reason, even though no changes to the content/ folder were made. For some other reason, this keeps on piling up in memory.

Context

• Hardware: Old laptop or computer
• YunoHost version: 11.2.9.1
• I have access to my server: Through SSH | through the webadmin | direct access via keyboard / screen | ... (all of it)
• Are you in a special context or did you perform some particular tweaking on your YunoHost instance?: no
  • If yes, please explain: The only tweak I did was to add /var/www/pelican/comment as an External Mount on Nextcloud following this comment and referring to the pelican-themes and pelican-plugins in my home directory, but that should not affect anything.
• Using, or trying to install package version/branch: 4.9.1~ynh1
• If upgrading, current package version: 4.9.1~ynh1

Steps to reproduce

1. update Pelican app to 4.9.1~ynh1
2. have articles in /var/www/pelican/content/ – if it is relevant, in my case, I have copied >400 of mine from my previous server
3. make sure that pelican.service is enabled in SysD
4. look at systemctl status pelican.service
5. wait for some time (e.g. 1h) without touching the content/ folder
6. look at systemctl status pelican.service again

Expected behavior

• no memory leak
• CPU usage only when a something changes in content/

Logs

YunoHost Logs show no issue – the update itself went fine.

But my systemctl status pelican.service currently looks like this:

● pelican.service - pelican monitor, to automatically rebuild your website
     Loaded: loaded (/etc/systemd/system/pelican.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2023-12-28 23:01:34 CET; 1h 36min ago
   Main PID: 211059 (pelican)
      Tasks: 1 (limit: 37697)
     Memory: 5.8G
        CPU: 1h 36min 46.890s
     CGroup: /system.slice/pelican.service
             └─211059 /var/www/pelican/venv/bin/python3 /var/www/pelican/venv/bin/pelican --autoreload

Dec 29 00:38:21 monolith.wheremymonkeyis.at pelican[211059]:            ERROR    Skipping                                           log.py:94
Dec 29 00:38:21 monolith.wheremymonkeyis.at pelican[211059]:                     /var/www/pelican/venv/lib/python3.9/site-packages/
Dec 29 00:38:21 monolith.wheremymonkeyis.at pelican[211059]:                     pelican/tests/output/custom/category/cat1.html:
Dec 29 00:38:21 monolith.wheremymonkeyis.at pelican[211059]:                     could not find information about 'date'
Dec 29 00:38:21 monolith.wheremymonkeyis.at pelican[211059]:            ERROR    Skipping                                           log.py:94
Dec 29 00:38:21 monolith.wheremymonkeyis.at pelican[211059]:                     /var/www/pelican/output/not-a-good-day-for-science
Dec 29 00:38:21 monolith.wheremymonkeyis.at pelican[211059]:                     .html: could not find information about 'date'
Dec 29 00:38:22 monolith.wheremymonkeyis.at pelican[211059]: [00:38:22] ERROR    Skipping                                           log.py:94
Dec 29 00:38:22 monolith.wheremymonkeyis.at pelican[211059]:                     /var/www/pelican/output/gravatar-support.html:
Dec 29 00:38:22 monolith.wheremymonkeyis.at pelican[211059]:                     could not find information about 'date'
Dec 29 00:38:22 monolith.wheremymonkeyis.at pelican[211059]:            ERROR    Skipping /var/www/pelican/output/index30.html:     log.py:94
Dec 29 00:38:22 monolith.wheremymonkeyis.at pelican[211059]:                     could not find information about 'date'

After 12' more, the Memory usage is up to even 6.5G. Smells like a mem leak to me.

[silverhook]

There was an issue with my Pelican set-up, which caused the service to constantly autoreload.

Now that I fixed that, the memory usage seems OK with 344M RAM, but perhaps that just means it’s leaking slower. Will keep an eye on it to see if it grows when I add new posts.