This command seems to do what is intended:
systemctl --plain --quiet --type=service --state=running  list-units|awk '/syncthing@/ {system("systemctl restart "$1)}'

Yeah. I know about this, but I'm not sure what the correct syntax for this scriptlet would be.
BTW, the glob has never worked, it's just that systemd on Fedora 34+ warns about it now.
I'll ask on the mailing list how to handle this correctly.

This is an omission from my side. The easiest solution (longer-term) is to allow such globs
in systemd. I filed a simple patch to do this [1]. When it goes through, I'll push it to
F34+ where the new scriptlet is used, and then it should be enough to rebuild this package.

[1] https://github.com/systemd/systemd/pull/20334

Actually… we don't even need to rebuild syncthing, it should just work when the new
systemd is installed.

I think you misunderstood me. The scriptlet warning about the glob does not come from a user unit (those are not templates), but a *system* unit, which are instantiated by username.


%post
%systemd_post 'syncthing@.service'
%systemd_user_post syncthing.service

%preun
%systemd_preun 'syncthing@*.service'
%systemd_user_preun syncthing.service

%postun
%systemd_postun_with_restart 'syncthing@*.service'
%systemd_user_postun_with_restart syncthing.service


The *user* variants are fine.
But I need to modify one of the calls for the instantiated *system* units to account for the fact they come from templates ...
And I don't know how to do that, since I do not understand the underlying systemctl commands.

Ok, after digging into the definition of the systemd scriptlets:


$ rpm -E "%systemd_post syncthing@*.service"

if [ $1 -eq 1 ] && [ -x /usr/bin/systemctl ]; then 
    # Initial installation 
    /usr/bin/systemctl --no-reload preset syncthing@*.service || : 
fi 

This is obviously nonsense. Applying presets to instantiated templates cannot work (which values of @i are supposed to be injected?)
So, can I just drop the %systemd_post scriptlet in this case?
The systemd service is not enabled by default, so users need to create an instantiated service anyway.



$ rpm -E "%systemd_postun_with_restart syncthing@*.service"
 
if [ $1 -ge 1 ] && [ -x /usr/bin/systemctl ]; then 
    # Package upgrade, not uninstall 
    for unit in syncthing@*.service; do 
         /usr/bin/systemctl set-property $unit Markers=+needs-restart || : 
    done 
fi 

The "systemctl set-property" command does not support globs, and hence does not support services that are instantiated from templates.
I'm pretty sure that at least the %systemd_postun_with_restart scriptlet used to work in previous releases.
And starting up my Fedora 33 VM, I see now why this is a new problem with Fedora 34, because in Fedora 33, this scriptlet does something different:

$ rpm -E "%systemd_postun_with_restart syncthing@*.service" 

 
if [ $1 -ge 1 ] && [ -x /usr/bin/systemctl ]; then 
        # Package upgrade, not uninstall 
        /usr/bin/systemctl try-restart syncthing@*.service || : 
fi 

And the "systemctl try-restart" command supports globs, while the "systemctl set-property" command does not.
So this is really a regression in the systemd RPM scriptlets between Fedora 33 and 34.

(In reply to Fabio Valentini from comment #6)
> Ok, after digging into the definition of the systemd scriptlets:
> 
> 
> $ rpm -E "%systemd_post syncthing@*.service"
> 
> if [ $1 -eq 1 ] && [ -x /usr/bin/systemctl ]; then 
>     # Initial installation 
>     /usr/bin/systemctl --no-reload preset syncthing@*.service || : 
> fi 
> 
> This is obviously nonsense. Applying presets to instantiated templates
> cannot work (which values of @i are supposed to be injected?)
> So, can I just drop the %systemd_post scriptlet in this case?
> The systemd service is not enabled by default, so users need to create an
> instantiated service anyway.

Please call "%systemd_post syncthing@.service". We support enablement of instances through
presets, and in theory users could make use of this by providing a local preset.

> $ rpm -E "%systemd_postun_with_restart syncthing@*.service"
>  
> if [ $1 -ge 1 ] && [ -x /usr/bin/systemctl ]; then 
>     # Package upgrade, not uninstall 
>     for unit in syncthing@*.service; do 
>          /usr/bin/systemctl set-property $unit Markers=+needs-restart || : 
>     done 
> fi 
...
> And the "systemctl try-restart" command supports globs, while the "systemctl
> set-property" command does not.
> So this is really a regression in the systemd RPM scriptlets between Fedora
> 33 and 34.

Yes.

FEDORA-2021-8480a19a6f has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-8480a19a6f

FEDORA-2021-8480a19a6f has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-8480a19a6f`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-8480a19a6f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-8480a19a6f has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.