This bug has been migrated to another issue tracking site. It has been closed here and may no longer be being monitored.

If you would like to get updates for this issue, or to participate in it, you may do so at Red Hat Issue Tracker .
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2056542 - Missing dependency on home dir for user@.service unit
Summary: Missing dependency on home dir for user@.service unit
Keywords:
Status: CLOSED MIGRATED
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: systemd
Version: 8.5
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Jacek Migacz
QA Contact: Frantisek Sumsal
URL:
Whiteboard:
Depends On: 2056527
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-02-21 13:26 UTC by Renaud Métrich
Modified: 2023-09-21 11:27 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-09-21 11:27:45 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker   RHEL-5899 0 None Migrated None 2023-09-21 11:27:38 UTC
Red Hat Issue Tracker RHELPLAN-112920 0 None None None 2022-02-21 13:34:34 UTC
Red Hat Knowledge Base (Solution) 6827941 0 None None None 2022-03-18 13:53:39 UTC

Description Renaud Métrich 2022-02-21 13:26:11 UTC 
Description of problem:

When having users with home dire on NFS and enabling lingering for such users, systemd fails to start the user@ service instance for the lingering user because the home dir is not present yet. This ends up not having the user services started.

IMHO user@.service should have the following property added, so that it gets delayed until home dir is available:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
RequiresMountsFor=%h
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Unfortunately due to BZ #2056527 "%h" cannot be used for now.


Version-Release number of selected component (if applicable):

systemd-239

How reproducible:

Always

Steps to Reproduce:
1. Create a user with home dir on NFS

2. Enable lingering for that user
3. Create a user service (/home/rmetrich/.config/systemd/user/test.service) and enable it

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
[Service]
ExecStart=/bin/sleep 3600

[Install]
WantedBy=default.target
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

4. Reboot

Actual results:

"systemd --user" loads but "test.service" unit is not known / didn't execute because "systemd --user" instance has a "null" configuration:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
$ systemctl --user status test
Unit test.service could not be found.
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Expected results:

"test.service" executes.

Additional info:

With the added dependency on home dir (hardcoded because "%h" fails), this works fine:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# systemctl cat user@$(id -u rmetrich)
[...]
# /etc/systemd/system/user@.service.d/home.conf
[Unit]
RequiresMountsFor=/home/rmetrich


$ systemctl --user status test
● test.service
   Loaded: loaded (/home/rmetrich/.config/systemd/user/test.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2022-02-21 14:24:54 CET; 24s ago
 Main PID: 1265 (sleep)
   CGroup: /user.slice/user-101166.slice/user/test.service
           └─1265 /bin/sleep 3600
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
Comment 1 Renaud Métrich 2022-02-21 13:58:00 UTC 
If the home dir is available through an autofs map, then the following drop-in needs to be added as well:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
After=autofs.service
Wants=autofs.service
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Adding all this as default should be pretty harmless.
Comment 2 David Tardon 2022-02-23 09:25:27 UTC 
(In reply to Renaud Métrich from comment #0)
> IMHO user@.service should have the following property added, so that it gets
> delayed until home dir is available:
> -------- 8< ---------------- 8< ---------------- 8< ---------------- 8<
> --------
> RequiresMountsFor=%h
> -------- 8< ---------------- 8< ---------------- 8< ---------------- 8<
> --------

This sounds reasonable to me.

> If the home dir is available through an autofs map, then the following
> drop-in needs to be added as well:
> -------- 8< ---------------- 8< ---------------- 8< ---------------- 8<
> --------
> After=autofs.service
> Wants=autofs.service
> -------- 8< ---------------- 8< ---------------- 8< ---------------- 8<
> --------
> 
> Adding all this as default should be pretty harmless.

But this does not. This is what synchronization targets are for. autofs.service should contain

Wants=remote-fs-pre.target
Before=remote-fs-pre.target

so, if it's *enabled*, it's guaranteed to be started before mounts are used (all "_netdev" "auto" mounts have After=remote-fs-pre.target).
Comment 3 Renaud Métrich 2022-02-24 08:23:40 UTC 
> But this does not. This is what synchronization targets are for.
> autofs.service should contain
> 
> Wants=remote-fs-pre.target
> Before=remote-fs-pre.target
> 
> so, if it's *enabled*, it's guaranteed to be started before mounts are used
> (all "_netdev" "auto" mounts have After=remote-fs-pre.target).

This doesn't work, because home dirs provided by autofs.service are not known to systemd at all before autofs.service really started (then they are known through the autofs mount point).

Also currently autofs.service even starts After=remote-fs.target, likely because autofs mount points can be set on top of static remote file systems in /etc/fstab.
Maybe this can be optimized by modifying autofs.service to also have a Wants=remote-fs.target so that the latter is really reached once autofs.service is started, but I don't know if it's legit to do so (i.e. having both After=remote-fs.target and Wants=remote-fs.target at the same time).

Anyway in the end, we need a new dependency in user@.service to delay at least until remote-fs.target is reached.
Comment 4 RHEL Program Management 2023-09-21 11:23:58 UTC 
Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.
Comment 5 RHEL Program Management 2023-09-21 11:27:45 UTC 
This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.
Note You need to log in before you can comment on or make changes to this bug.