Description of problem:
Systemd doesn't allow to set User in service files to a username with a dot in it.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create a test user as below
# useradd red.hat
# passwd red.hat
2. Create a test script as below
# vi /usr/lib/systemd/system/SMHI-startscript.service
3. Reload systemd daemon to reflect the changes and start the service
# systemctl daemon-reload
# systemctl start SMHI-startscript.service
● SMHI-startscript.service - SMHI-startscript
Loaded: bad-setting (Reason: Unit SMHI-startscript.service has a bad unit file setting.)
Active: inactive (dead)
Jun 06 00:28:25 rhel8-12.gsslab.pnq2.redhat.com systemd: /usr/lib/systemd/system/SMHI-startscript.service:14: Invalid user/group name or numeric ID: red.hat
Jun 06 00:28:30 rhel8-12.gsslab.pnq2.redhat.com systemd: /usr/lib/systemd/system/SMHI-startscript.service:14: Invalid user/group name or numeric ID: red.hat
Jun 06 00:39:06 rhel8-12.gsslab.pnq2.redhat.com systemd: /usr/lib/systemd/system/SMHI-startscript.service:14: Invalid user/group name or numeric ID: red.hat
# systemctl status SMHI-startscript.service
● test1.service - Test
Loaded: loaded (/etc/systemd/system/SMHI-startscript.service; disabled; vendor preset: disabled)
Active: active (exited) since Wed 2019-06-05 18:43:11 EDT; 2min 56s ago
Process: 2126 ExecStart=/bin/bash /home/red.hat/test.sh (code=exited, status=0/SUCCESS)
Main PID: 2126 (code=exited, status=0/SUCCESS)
Jun 05 18:43:10 localhost.localdomain systemd: Starting SMHI-startscript...
Jun 05 18:43:11 localhost.localdomain systemd: Started SMHI-startscript...
From my point of view, we should fix this.
Thanks, would really like this to be fixed as it would give us problems otherwise as we use different .suffix for different user account types (production, test, dev etc).
See the upstream issue.
I'm wondering about this paragraph from upstream issue:
"Note that this restriction hsa been in place since a long long time in systemd, hence we don't even break compatibility here: it's not that we suddenly broke unit files that previously worked with systemd that no longer work."
This restriction is NOT in place in RHEL7, so for a RHEL customer this is a potentially breaking change (it is for us, causing a LOT of extra work to migrate to RHEL8). So, is a 'fix' for the rhel8 package really out of the question?
A middle ground would be to make the behaviour configurable in systemd and thus leaving it to the user to decide.
(In reply to adam winberg from comment #4)
> So, is a 'fix' for the rhel8 package really out of the question?
> A middle ground would be to make the behaviour configurable in systemd and
> thus leaving it to the user to decide.
I don't think it's out of the question, but I'm not willing to do another rhel-only patch. But the final decision is not mine. If you want, you can reopen this bugzilla so other members of the systemd team can give their opinions. I have already given mine, but the upstream disagrees.
As to the "middle ground", I don't think that there is one. We either enable the dot or not. Making it somehow configurable (compile time option? program argument?) would be way too complicated for what the functionality is supposed to be.
As per my opinion , this is a must requirement . and we might expect alot of other customers to demand for the same.
If it is somehow possible to include this feature back, i am reopening this bugzilla, lets see if any other member has to say something on it.
The fix has been merged in upstream in https://github.com/systemd/systemd/pull/13244. There's also a commit (https://github.com/systemd/systemd/pull/13244/commits/88e2ed0b5bf6f08f5a2d4d64b1fefdc7192b9aac) which causes systemd to emit warning for usernames with a dot with them which should be, probably, discussed before backporting, as some customers may not like that.
I suggest to allow the dot only, without the warning. The warning was an idiosyncratic decision, really.
fix merged to github master branch -> https://github.com/systemd-rhel/rhel-8/pull/25 -> post