| Summary: | Systemd occasionally blocks on boot | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Zdenek Kabelac <zkabelac> | ||||||||||||
| Component: | systemd | Assignee: | systemd-maint | ||||||||||||
| Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||||
| Priority: | unspecified | ||||||||||||||
| Version: | rawhide | CC: | johannbg, lnykryn, mschmidt, msekleta, plautrba, systemd-maint, vpavlin, zbyszek, zkabelac | ||||||||||||
| Target Milestone: | --- | ||||||||||||||
| Target Release: | --- | ||||||||||||||
| Hardware: | Unspecified | ||||||||||||||
| OS: | Unspecified | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||
| Clone Of: | Environment: | ||||||||||||||
| Last Closed: | 2014-06-18 09:21:10 UTC | Type: | Bug | ||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||
| Documentation: | --- | CRM: | |||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||
| Attachments: |
|
||||||||||||||
I suggest to enable debug-shell.service and use it to explore the state of the system when the problem happens again. With debug-shell.service you'll have a root shell running on tty9. "systemctl list-jobs" would be the first command to try in this situation. Then check the status of services whose jobs are shows as "running". Created attachment 824966 [details]
list-jobs
list of jobs - executed from debug console
Created attachment 824967 [details]
mount info
Info about mounts in the system.
Created attachment 824969 [details]
status of active processes
status of already running process.
Created attachment 824972 [details]
Matching dmesg
dmesg from this moment.
Interesting related to binfmt could be this message in the log:
[ 2.325426] systemd[1]: proc-sys-fs-binfmt_misc.automount's automount point already active?
though I've no idea what is the reason for problems.
So what else should I run next time I notice this problem?
1. Where does jexec.service (is it /etc/init.d/jexec?) come from? Can you attach it here? 2. Does it every continue on its own? Did you let it sit for >5 min? 3. Does it work if mask jexec.service? No it never continued and in fact usually it happens exactly in the moment I need quick reboot. I could hardly confirm if it would help to mask - since it blocks my boot rather occasionally, so it's not easy to say the problem has been solved. It seems jexec.service comes from jre-1.6.0_32-fcs.x86_64 - which is probably Oracle package to make Java usable in firefox. Anyway - I've uninstalled this package since I've not used any java program for years so I'll see if my problem disappears. Any update? Since I've uninstalled 'jre' - I no longer observing this problem, so for this case has been solved. OK, closing then. |
Created attachment 823593 [details] boot message log Description of problem: It's hard to give here exact details - but it happens from time to time, that my Fedora boot blocks itself waiting on something. Whenever I try to run systemd with debug levels I'm not able to reproduce the issue - and it also quite unpredictable even normally. I suspect some synchronization order - maybe someone here could give some hint how to slow down some services to trigger problems from my boot log trace. In the trace - after some wait when there was no progress - I've pressed sysrq+t to capture all process - and then I've pressed sysrq+i which is 'good enough' usable workaround for me - after this boot completes. Here is my fstab: /dev/sda2 / ext4 noatime,data=ordered 1 1 /dev/sda1 /boot ext4 noatime,noauto,comment=systemd.automount,noatime, data=ordered 1 2 /dev/sda6 /home ext4 noatime,data=ordered,user_xattr 1 2 Version-Release number of selected component (if applicable): systemd-208-4.fc21.x86_64 (the problem is there for long time) How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: