Project

General

Profile

Actions

Feature #2148

closed

IIIF: check IIPImage and systemd

Added by Alexander Watzinger 2 months ago. Updated about 1 month ago.

Status:
Closed
Priority:
Normal
Category:
IIIF
Target version:
Start date:
2024-01-02
Estimated time:

Description

It seems like systemd is trying to start IIIF when booting but fails because it doesn't find the config:

systemd[1]: iipsrv.service: Failed with result 'resources'.
systemd[1]: Failed to start iipsrv.service - IIPImage server.
systemd[1]: iipsrv.service: Failed to load environment files: No such file or directory
systemd[1]: iipsrv.service: Failed to run 'start' task: No such file or directory
We should look into this, see https://iipimage.sourceforge.io/documentation/server, questions would be:
  • Are the multiple IIIF instances started and do we want this?
  • Do we want systemd to start IIIF?
    • If yes: configure and test it. Should we than change something at Apache? How to document it (also for non Debian users)?
    • If no: how we stop systemd trying it
Actions #1

Updated by Alexander Watzinger 2 months ago

  • Description updated (diff)
Actions #2

Updated by Alexander Watzinger about 2 months ago

  • Assignee set to Bernhard Koschiček-Krombholz
Actions #3

Updated by Alexander Watzinger about 2 months ago

  • Status changed from Acknowledged to Assigned
Actions #4

Updated by Bernhard Koschiček-Krombholz about 2 months ago

The Debian package in fact supports 2 different ways to start iipsrv and you should one or the other.
The first way is by having Apache (or Lighttpd) start and manage iipsrv automatically for you. In this case, the file /etc/apache2/mods-available/iipsrv.conf will be used.
The 2nd way is via systemd. In this case, the configuration options are provided through /etc/default/iipsrv and you can start and manage the process independently of any web server by using the systemctl command. Systemd support was indeed introduced between Debian 9 and 11. Though, it would definitely be better if the file /etc/default/iipsrv was installed by default.

https://sourceforge.net/p/iipimage/discussion/299494/thread/1244de3c74/#2634 (from the main developer of iipimage)

So one service is enough. Since we are happy with the Apache service, we can just deactivate the systemd service with

sudo systemctl disable iipsrv.service

That will fix the errors on boot and there will no other service run besides the Apache one.

The question is, if you want to purge all systemd data for clean up. I won't recommend it, because it is rather lightweight, and maybe we destroy something in the process.

Actions #5

Updated by Bernhard Koschiček-Krombholz about 2 months ago

  • Status changed from Assigned to Resolved
Actions #6

Updated by Alexander Watzinger about 2 months ago

  • Status changed from Resolved to In Progress
  • Assignee changed from Bernhard Koschiček-Krombholz to Alexander Watzinger
Thanks for looking into it. I will change and test that on our servers (but after the presentation tomorrow) and will than give feedback about it.
Checklist for myself:
  • Test local
  • Test on trinity
  • Test at ACDH-CH
  • Add to installation notes
  • Close issue
Actions #7

Updated by Alexander Watzinger about 1 month ago

  • Subject changed from IIIF: check IIIF and systemd to IIIF: check IIPImage and systemd
  • Assignee changed from Alexander Watzinger to Bernhard Koschiček-Krombholz

When looking into it I stumbled over another warning:

Useless use of AllowOverride in line 6 of /etc/apache2/mods-enabled/iipsrv.conf

Turned out because AllowOverride was used in a location context and not in a directory context. According to our iipsrv config example:
...
# Set the options on that directory
<Location "iipsrv/">
   AllowOverride None
...

At the IIPImage documentation (https://iipimage.sourceforge.io/documentation/server) they are using <Directory> instead our <Location> directive where the AllowOverride None actually make sense.
I guess we should either change location to directory or remove/replace the AllowOverride.
Because I don't know if there is a reason for the difference in our installation example I hand this back to Bernhard for further review.

Please assign it back to me once solved for further testing.

Actions #8

Updated by Alexander Watzinger about 1 month ago

  • Status changed from In Progress to Closed
  • Assignee changed from Bernhard Koschiček-Krombholz to Alexander Watzinger

I was impatient so I just changed the location -> directory thing myself, tested it together with disabling the systemd start up script and it seemed to work fine.
In case the location (instead directory) directive had some deeper meaning please let me known. Otherwise I would say this is solved.

Actions

Also available in: Atom PDF