Avoid failing the service when running in a container

[cpaelzer]

Hi,
I was for some test installing python-rtslib-fb in a container. I'd not have expected it to work7do anything there but it came in as dependency. Now all that is fine, but the apt/dpkg installation broke on it.

root@f:~# systemctl status rtslib-fb-targetctl.service
● rtslib-fb-targetctl.service - Restore LIO kernel target configuration
     Loaded: loaded (/lib/systemd/system/rtslib-fb-targetctl.service; disabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Thu 2020-02-27 14:10:35 UTC; 3s ago
    Process: 23831 ExecStart=/usr/bin/mkdir -p /etc/rtslib-fb-target (code=exited, status=0/SUCCESS)
    Process: 23832 ExecStart=/usr/bin/targetctl restore (code=exited, status=1/FAILURE)
   Main PID: 23832 (code=exited, status=1/FAILURE)

Feb 27 14:10:35 f target[23832]: File "/usr/bin/targetctl", line 47, in restore
Feb 27 14:10:35 f target[23832]: errors = RTSRoot().restore_from_file(restore_file=from_file)
Feb 27 14:10:35 f target[23832]: File "/usr/lib/python3/dist-packages/rtslib_fb/root.py", line 85, in __init__
Feb 27 14:10:35 f target[23832]: modprobe('target_core_mod')
Feb 27 14:10:35 f target[23832]: File "/usr/lib/python3/dist-packages/rtslib_fb/utils.py", line 428, in modprobe
Feb 27 14:10:35 f target[23832]: raise RTSLibError(stderrdata)
Feb 27 14:10:35 f target[23832]: rtslib_fb.utils.RTSLibError: b"modprobe: ERROR: ../libkmod/libkmod.c:611 kmod_search_moddep() could not open moddep file '/lib/modules/5.3.0-40-generic/modu>
Feb 27 14:10:35 f systemd[1]: rtslib-fb-targetctl.service: Main process exited, code=exited, status=1/FAILURE
Feb 27 14:10:35 f systemd[1]: rtslib-fb-targetctl.service: Failed with result 'exit-code'.
Feb 27 14:10:35 f systemd[1]: Failed to start Restore LIO kernel target configuration.

The reason for that was, that it tried to start and broke on the inability to load modules.
I'd prefer to make this error more graceful and not making apt consider the installation failed.

I was now wondering - and wanted to discuss - if you'd agree that there is no in-container use-case in which we might just add ConditionVirtualization=!container to the service and would be fine.

If there is an in-container use case we might find a better/smarter way to guard it from failing.
But in that case I'd appreciate if one could outline how that container use-case could work so that the solution to skip the service in "just the right cases" can align to that.