Bug 693885

Summary: /home on NFS, plus sandbox service enabled makes sytem hang on boot
Product: [Fedora] Fedora Reporter: Severin Gehwolf <sgehwolf>
Component: systemdAssignee: systemd-maint
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 15CC: adam, johannbg, johannbg, johannbg, lpoetter, metherid, mschmidt, notting, plautrba, sgehwolf
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-01-25 19:22:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Severin Gehwolf 2011-04-05 19:52:48 UTC
Description of problem:
I'm running a system where I have /home on NFS and use NIS (should be unrelated). My local network is managed by the network service. 

Version-Release number of selected component (if applicable):
# rpm -qf /etc/init.d/sandbox 
policycoreutils-2.0.85-27.fc15.x86_64
rpm -q systemd
systemd-22-1.fc15.x86_64

How reproducible:
Unsure, but it hung each time I rebooted and the sandbox service was enabled. Disabling it, made it work again.

Steps to Reproduce:
1. enable network service (systemctl enable network.service)
2. disable NetworMangager service (systemctl disable NetworkManager.service)
3. Make /home NFS mounted (I have comment=systemd.automount for my /home in /etc/fstab)
4. Reboot
5. System hangs when trying to bring up the sandbox service (probably, due to the fact that the network is not up yet)
  
Actual results:
System hangs on boot when attempting to start the sandbox service (I probably did not sit it out long enough; maybe it's just taking a very long time).

Expected results:
No hang on boot (maybe disable sandbox or do something otherwise reasonable).

Additional info:
Let me know if you need more :) Thanks!

Comment 1 Severin Gehwolf 2011-04-05 19:53:51 UTC
I forgot to mention that the my current workaround is to disable the sandbox service. No idea why it was enabled in the first place :)

Comment 2 Lennart Poettering 2011-04-12 12:03:59 UTC
Any chance you can log in while this is hanging and get us an output of "ps xawf -eo pid,args,cgroup"?

If you wait 3min, does the boot finish?

Comment 3 Severin Gehwolf 2011-04-13 20:34:48 UTC
As far as I remember, this happens too early in the boot process. I.e. before any getty's get started. So I'm unsure how I would be able to log in an provide this info :)

I'll enable the sandbox service later today and will report back what I find.

Comment 4 Severin Gehwolf 2011-04-13 22:14:48 UTC
Ok, so here is what I found: This is only happening if the network service is used instead of NetworkManager. If the latter is used and the sandbox service is enabled, my /home mount fails. Probably, because /home is an NFS share with root squashing turned on and sandbox wants to do something in /home as root. Anyhow, back to the network + NFS + sandbox issue:

1. This is way too early in the boot process to be able to log in and issue any command. In fact, the only key combination which has any effect is ctrl+alt+DEL (which reboots). The only way to fix this is to boot into single user mode and disable the sandbox service.

2. Waiting 5 minutes does not change anything. It hangs and it looks like it's hanging there forever.


If you have any more thoughts on this, please let me know. Thanks!

Comment 5 Lennart Poettering 2011-04-28 20:15:36 UTC
I figure this is sandbox doing bind mounts on /home. I am not even sure this can work properly if an fs without labelling is used, such as NFS.

I figure netfs is spawned start from the network hook scripts and this conflicts with sandbox in some way...

might be a bug that is unrelated to systemd.

Comment 6 Fedora Admin XMLRPC Client 2011-10-20 16:26:58 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 7 Jóhann B. Guðmundsson 2012-01-24 11:30:48 UTC
Is this still a problem or can this bug be closed?

Comment 8 Jóhann B. Guðmundsson 2012-01-25 19:22:46 UTC
Closing this bug as notabug until confirmed otherwize 

If this is still an issue feel free to reopen it thanks.