RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 784960 - Unable to target fsck with timed system reboots (shutdown -rF ...)
Summary: Unable to target fsck with timed system reboots (shutdown -rF ...)
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: upstart
Version: 6.1
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Lukáš Nykrýn
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-26 19:03 UTC by Todd
Modified: 2012-01-27 18:34 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-27 09:29:29 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Todd 2012-01-26 19:03:40 UTC 
Hi All,

I am coming from the community (Scientific Linux 6.x).  This was originally bug https://bugzilla.redhat.com/show_bug.cgi?id=733874 which got hot potatoed over to Fedora.  Please do not do that again.  This is a sys admin problem with servers, not workstations (well maybe a little).

Here is the problem.  I can not tell you how many times I have issued the "shutdown -rF 22:00 &" command to fix a server whose kernel fail to properly mount an AHCI removable backup hard drive.  The "-F" to get the fsck out of the way so as to avoid it happening to the customer during the middle of their work day when they have to do a manual reboot for whatever reason.  (They get really, really mad/pissed while they have to wait and wait while their business slips by and they look stupid to their customers).  And "-F" has been removed from the "shutdown" command. 

We have a lot of power outages, I have customers that shut their computer off a night and the weekends, and I "had" a nut case that thought a Linux server was a Windows server and he flipped the power off on it if his workstation's mouse doesn't work correctly.

From the Fedora bug, Jóhann states:
https://bugzilla.redhat.com/show_bug.cgi?id=733874#c12

> So after a bit of discussion and to put long story short this got ripped out
> because the interface is seriously broken.

>This will not be implemented or officially supported in systemd in any shape
> or form until there's a sane way to request an fsck for the next boot 
> without actually mucking with the fs in question for example if/when pstore
> one day would allow this. ( The solution will most likely be implemented in
> dracut ).

> What this means is that the "F" option is not coming back but reboot with
> fsck at precise time might sometime in the distant future ( think year or
> two ). 

Yes, you an still use "touch /forcefsck ; shutdown -r 22:00 &" and just hope, hope the customer does not reboot for any reason before then.  Not a reasonable risk in server environment.

So, please fix systemd.  Be nice if it appeared in RHEL 6.3.

Many thanks,
-T
Comment 2 Kay Sievers 2012-01-26 21:23:16 UTC 
I don't think 'init' has much of a job in controlling fsck behaviour with 'init'
commandline options. It is gone for good, and that long before systemd was on
the table.

Let alone the absolute brokenness of the general idea, to need to write to
the mounted filesystem, to force a check of it.

If you want the old behavior, why not just use:
  $ sleep 8h; touch /forcefsck; reboot

or use 'at' for it, which accepts all sorts of fancy options.

For systemd, we do not want to add any fsck controls, and RHEL6 will not
ship systemd anyway.

I think this bug can also be closed again. :)
Comment 3 Lukáš Nykrýn 2012-01-27 09:29:29 UTC 
According to upstream bugzilla
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/74139
it is very unlikely, that they will accept any patch to add this feature and
there are many other ways how to achieve this behavior.
Comment 4 Todd 2012-01-27 18:34:23 UTC 
(In reply to comment #2)

> If you want the old behavior, why not just use:
>   $ sleep 8h; touch /forcefsck; reboot

Don't want to leave a terminal or a user logged in.  All sorts of mischief, yada yada yada.  I suppose there is a way to use the "&" thing to with a run on command ...

> or use 'at' for it, which accepts all sorts of fancy options.

Means I have to look it up every time I use the command.  I have used Red Hat products for 15 years or so and I like to use what I know by heart that I used for so many years.  Forced myself to learn the dreaded vi back then too.  Would just like to see some continuity for an easy to use command.

Looks like I don't get my way on this one.  Oh well.  Thank you all for your patience.

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