Bug 1010697
| Summary: | why does it do this stuff at this time? | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | udo <udovdh> |
| Component: | systemd | Assignee: | systemd-maint |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 19 | CC: | johannbg, lnykryn, msekleta, plautrba, systemd-maint, vpavlin, zbyszek |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | systemd-204-16.fc19 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-10-08 11:38: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: | |
| Embargoed: | |||
|
Description
udo
2013-09-22 15:41:51 UTC
Hi, we haven't had issues with systemd reexecuting spontaneously, afaik. It will reexecute when it either receives a dbus signal or a unix signal (TERM). Any ideas on what could have sent a signal? If you put systemd in debug mode (kill -56 1), it'll log dbus communications. Regarding the restarting of fsck units: this has been fixed post-204: http://cgit.freedesktop.org/systemd/systemd/commit/?id=d0a2d726, http://cgit.freedesktop.org/systemd/systemd/commit/?id=ef7e6e0598 and other commits which do related changes for similar units. I'm not sure if we got all of them... If such spurious restarts of units happen post-207, please report them. I do not have any visible controle over dbus and I was not oat the system to give it a kill -whatever. Aside from the reexecution we see that systemd is not aware of the situation of the system, does not even bother to even check, and thus goes along with stuff that you would expect during a system startup. That is very strange indeed as it could hose a system very badly. Please adjust your code to check stuff before you execute certain commands on the system. Why fsck when the stuff is mounted already? Why mount it first before checking if it is already mounted? Together with the mertg stuff and the logging stuff I do think that systemd is a step too far. The init replacement is OK as it provides a quicker boot if no issues are encountered. The rest should be skipped as soon as possible. (!!) Please stay true to the core of the project. Please do not do stuff 'because we can' as it appears to contradict UNIX itself as I know it. (In reply to udo from comment #2) > I do not have any visible controle over dbus and I was not oat the system to > give it a kill -whatever. If "oat" means "own", then sorry, you can't debug stuff without necessary privileges. > Aside from the reexecution we see that systemd is not aware of the situation > of the system, does not even bother to even check, and thus goes along with > stuff that you would expect during a system startup. > That is very strange indeed as it could hose a system very badly. It doesn't hose the system, since fsck does not run on a mounted filesystem, so it's just a bunch of misleading messages. It was a bug, noticed and fixed after F19 was released. The fix has certain side-effects and thus wasn't backported to F19. > Please adjust your code to check stuff before you execute certain commands > on the system. Right, fsck does check, and (with the fix) systemd doesn't try to invoke it after the filesystem has been mounted anymore. > Why fsck when the stuff is mounted already? It was a bug. > Why mount it first before checking if it is already mounted? It doesn't actually get mounted again. > Together with the mertg stuff and the logging stuff I do think that systemd > is a step too far. mertg stuff? > The init replacement is OK as it provides a quicker boot if no issues are > encountered. > The rest should be skipped as soon as possible. (!!) > Please stay true to the core of the project. > Please do not do stuff 'because we can' as it appears to contradict UNIX > itself as I know it. I'm sorry that you encounter issues, but the First in Fedora unfortunately means that sometimes you get stuff which you get to find bugs in. You might want to create a file /etc/systemd/system/systemd-fsck@.service.d/90-remain.conf with the following contents: ------------------------------- [Service] RemainAfterExit=yes ------------------------------- and similar for other units which get needlessly started twice. (In reply to Zbigniew Jędrzejewski-Szmek from comment #3) > (In reply to udo from comment #2) > > I do not have any visible controle over dbus and I was not oat the system to > > give it a kill -whatever. > If "oat" means "own", then sorry, you can't debug stuff without necessary > privileges. A misspelling of "at" seems more likely. > > Together with the mertg stuff and the logging stuff I do think that systemd > > is a step too far. > mertg stuff? Likely "mrtg stuff", referring to bug 911766. oat -> at If the disks are mounted, why even start fsck? Why not backport to F19 if that release has 'support'/'maintenance' or whatever euphemism is en vogue these days? If fsck is to be relied on then systemd does simply fire off commands. What is the added value if systemd is apparantly not aware of the situation before even deducing what to do? mertg -> mrtg. The con-job replacement that logs way too much in the wrong places. Not a task for an init-replacement. No progress, but a step backwards. See bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=984565. Ask Lennart P. Also ask him about the reasons for the journalctl stuff over cat/less/more/grep etc in the 'classic' log files. Where is my ~/.xinit-errors? Does that stuff really belong in /var/log/messages? The Fedora folks are messing up a good UNIX system for no good reason as I did not yet get pointed towards a good read explaining all this. Together with the breakneck upgrade schedule/speed and the perceived lack of attention and thus support for core issues: what is Fedora aiming at and what does it think it is doing to get there? We might perceive a different thing here. (I did not yet mention the upgrade procedure which is utterly broken as I discovered by going from F17 to F19: we cannot do a upgrade via DVD, the ketchup or whatever tool is broken on anything that has raid, crypto, etc and yum needs somebody that is not afraid of dependency hell. Do you really want to press this onto users? Please think again. Looks like https://bugzilla.redhat.com/show_bug.cgi?id=974122 might be related. Please stop setting needinfo on various bugs to their owners. This is a tool for bug owners. We are aware, really, of this bug, and the other 200 open bugs, and 150 or so on freedesktop.org. You're not helping by adding noise. systemd-204-16.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/systemd-204-16.fc19 This update should be a partial fix, please test that the fsck's don't happen. systemd-204-16.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. |