I was thinking of dropping systemd.template.xsan.service.in completely and use a drop-in file for Environment options for ASAN/MSAN/TSAN instead of maintaining two virtually identical files. WDYT?

It's not possible as you can't make certain sections "drop in" IIRC. I experimented with this and chose the split file method to avoid this. I could be mistaken here or it's changed since, but previous attempts were not valid unit files :(

Is it possible to show an "example" drop in, or link to the systemd.template.service.custom.conf.in somehow to guide admins to the "how" to achivee this?

It's not possible as you can't make certain sections "drop in" IIRC. I experimented with this and chose the split file method to avoid this. I could be mistaken here or it's changed since, but previous attempts were not valid unit files :(

I'm sorry to disappoint, but this is exactly what drop-in files are for: to override certain parameters in certain sections. This functionality is in systemd for quite a while.

Here's an example:

[vashirov@server ~]$ cat .config/systemd/user/hello.service
[Unit]
Description=Service that prints a greeting
[Service]
ExecStart=/usr/bin/echo "Hello ${WORLD}"
Environment=WORLD=World
[Install]
WantedBy=default.target
[vashirov@server ~]$ systemctl --user daemon-reload
[vashirov@server ~]$ systemctl --user start hello
[vashirov@server ~]$ journalctl --user -u hello
-- Logs begin at Thu 2019-05-30 00:35:33 EDT, end at Thu 2019-05-30 00:37:39 EDT. --
May 30 00:37:39 server.example.com systemd[1039]: Started Service that prints a greeting.
May 30 00:37:39 server.example.com echo[1085]: Hello World
May 30 00:37:39 server.example.com systemd[1039]: hello.service: Succeeded.

Now let's create an override:

[vashirov@server ~]$ systemctl --user edit hello

This will open an $EDITOR, but you can create drop-in directory by hand an place a .conf file there yourself.

[vashirov@server ~]$ cat .config/systemd/user/hello.service.d/override.conf
[Unit]
Description=Service with an overrided description
[Service]
Environment=WORLD="Down Under"
[vashirov@server ~]$ systemctl --user start hello
[vashirov@server ~]$ journalctl --user -u hello
-- Logs begin at Thu 2019-05-30 00:35:33 EDT, end at Thu 2019-05-30 00:39:00 EDT. --
May 30 00:37:39 server.example.com systemd[1039]: Started Service that prints a greeting.
May 30 00:37:39 server.example.com echo[1085]: Hello World
May 30 00:37:39 server.example.com systemd[1039]: hello.service: Succeeded.
May 30 00:39:00 server.example.com systemd[1039]: Started Service with an overrided description.
May 30 00:39:00 server.example.com echo[1096]: Hello Down Under
May 30 00:39:00 server.example.com systemd[1039]: hello.service: Succeeded.

Is it possible to show an "example" drop in, or link to the systemd.template.service.custom.conf.in somehow to guide admins to the "how" to achivee this?

We can point them to man systemd.unit where it is described.

I've added a change as Viktor suggested. @firstyear Please have a look. This drop-in file will be installed in case the server is built with a sanitizer and automatically picked up by systemd.

It's not possible as you can't make certain sections "drop in" IIRC. I experimented with this and chose the split file method to avoid this. I could be mistaken here or it's changed since, but previous attempts were not valid unit files :(

I'm sorry to disappoint, but this is exactly what drop-in files are for: to override certain parameters in certain sections. This functionality is in systemd for quite a while.

This is not my point. I know how drop in's work. My point was that drop in files may not function for some configuration sections in the unitfile. IIRC if you try to drop in over exec or certain other parameters you have to make a new unit file because you can't replace that statement. So if this works, whatever you are "replacing" is not falling under these rules. Additionally my comment was to ask you to check that it actually was working, because there are some conditions where the drop in is not used because of the requirement that you have to use or replace the section.

So if this is working for you, and tested, then great. But bear in mind there are some things that can not be drop-in overriden ...

We can point them to man systemd.unit where it is described.

I think I mean that our unitfile should say something like:

# To configure this, create a drop in file in:
# /etc/systemd/system/dirsrv.whatever.target.d/example.com
# It's contents should be from ...
# For more see <man page> 

... IIRC if you try to drop in over exec or certain other parameters you have to make a new unit file because you can't replace that statement. ...

IIUC what your concern is, you can do e.g. ExecStart= (that is, without a value) in a drop-in file first which resets the value and subsequent assignmnets would build the value of it again.

... So if this is working for you, and tested, then great. But bear in mind there are some things that can not be drop-in overriden ...

At least me and Mark have successfully tested this to find it working as expected.

I think I mean that our unitfile should say something like:

The main .service file contains pointer to the drop-in file where supposed handling is described -- do you find this sufficient? Suggestions to particular changes are welcome. :)

Yep, that's fine, if it's all tested then my concerns are covered.

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/3469

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.