Bug 799574 - Cannot cancel fsck
Cannot cancel fsck
Status: CLOSED DUPLICATE of bug 719952
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Michal Sekletar
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-03 01:54 EST by Eric Appleman
Modified: 2012-10-30 14:11 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-30 14:11:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eric Appleman 2012-03-03 01:54:23 EST
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 07:26:25 EDT
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 13:09:21 EDT
Any particular reason why we simply dont just default to this?
Comment 3 Michal Sekletar 2012-07-20 08:22:17 EDT
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 11:55:17 EDT
Note this bug is filed against Fedora so RHEL behaviour is irrelevant here...
Comment 5 Lennart Poettering 2012-10-30 14:11:42 EDT
(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 ***

Note You need to log in before you can comment on or make changes to this bug.