As I have expressed myself before, I don't think that's a good idea. Services should be simpler and more predictable. Using an EnvironmentFile to configure anything service-specific is a bad idea itself, and making Type of service configured through it is even worse.

IMO irqbalance should either provide two separate units for users to choose from, or just plain daemon service file. Adding additional service file in the future wouldn't cause problems; while introducing invalid files right now will make it harder to fix them in the future -- because users will start relying on them.

Users have relied on --oneshot in irqbalance for years, without issue.  The way things "should" be isn't relevant when people have been using a feature effectively without issue.  Nobody expects to have two separate services to start when they've been expecting an environmental config option.

(In reply to comment #2)
> Users have relied on --oneshot in irqbalance for years, without issue.  The way
> things "should" be isn't relevant when people have been using a feature
> effectively without issue.  Nobody expects to have two separate services to
> start when they've been expecting an environmental config option.

systemd users aren't expecting environmental config options. systemd users expect that services should be able to handle their configs without random convoluted hacks.

And systemd users expect multiple separate services. This is how things work. You can use sshd.service to run sshd as a daemon, or sshd.socket to run it on inetd-like basis. Noone expects random /etc/foobarbaz/sshd.magicaloptions with PUT_SOME_RANDOM_STRING_HERE_TO_ENABLE_INETD=and-also-a-few-other-hacks-to-change-service-type.

Its not you're world to control.  There are far more than just systemd users out there, and older, more established init systems have all worked with the existing configuration method.  The fact that you dont' want systemd to work that way doesn't make the old method wrong.

(In reply to comment #4)
> Its not you're world to control.  There are far more than just systemd users
> out there, and older, more established init systems have all worked with the
> existing configuration method.  The fact that you dont' want systemd to work
> that way doesn't make the old method wrong.

And how are non-systemd users related to systemd unit files? Are you suggesting that systemd should be changed to match old rc systems just because things were like that in the past?

No, I'm suggesting that systemd make a very minor concession to provide a modicum of compatibility to the way systems services have operated up until this point.  I would have thought that would have been clear in this bug description.

You can always drop a snippet into /run/systemd/system/<service>.d/type.conf with something like

[Service]
Type=oneshot

and whatever other adjustments are needed. But like Michał said, it's not a very good idea, it's very specific and doesn't really work in general, since most servcies require different options to start in "oneshot" mode. Once you have different Type, and different options, it's actually better to have two unit files.