Bug 799574

Summary:	Cannot cancel fsck
Product:	[Fedora] Fedora	Reporter:	Eric Appleman <erappleman>
Component:	systemd	Assignee:	Michal Sekletar <msekleta>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	17	CC:	johannbg, lpoetter, metherid, msekleta, notting, plautrba, systemd-maint
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:	2012-10-30 18:11:42 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Eric Appleman 2012-03-03 06:54:23 UTC

With sysv or upstart, an fsck can normally be canceled with C or CTRL+C.

No such functionality exists for systemd and is quite frustrating since I mount my drives in weird ways.

Comment 1 Michal Sekletar 2012-07-19 11:26:25 UTC

You can edit /usr/lib/systemd/system/fsck@.service and add line StandardInput=tty, thus stdin of fsck will be connected to /dev/console (default unless in TTYPath= specified otherwise) and then pressing C-c should cancel filesystem check.

Comment 2 Jóhann B. Guðmundsson 2012-07-19 17:09:21 UTC

Any particular reason why we simply dont just default to this?

Comment 3 Michal Sekletar 2012-07-20 12:22:17 UTC

This is up to Lennart to decide, however I'm not sure this was default with upstart, as stated in Description. It could be done by setting 'console owner' instead of 'console output' option, thus if this was not default in RHEL6, then I'd say we should leave it as it is now, and it's up to administrator to change it as desired.

Comment 4 Jóhann B. Guðmundsson 2012-07-21 15:55:17 UTC

Note this bug is filed against Fedora so RHEL behaviour is irrelevant here...

Comment 5 Lennart Poettering 2012-10-30 18:11:42 UTC

(In reply to comment #2)
> Any particular reason why we simply dont just default to this?

If an fsck is started after boot is complete we really shouldn't try to take posession of /dev/tty1 again, since X11 or a getty might run on it, and things would get very confused if we'd try to read input from that.

*** This bug has been marked as a duplicate of bug 719952 ***