fstab remount as Read-Only

H

hac3ru

Hello,

I've got an issue with a FreeBSD 10.3. From time to time, the server's cut from power (long story short, the world's full of electrical engineers who don't know what they're doing) and I've got a drive, /dev/da1 with a partition /dev/da1p1 that's used to save pflogs. Well, at power failure, this partition gets corrupted (expected, since information's written on it all the time). When the server boots up, it sees the drive as corrupted and panics, asking me to run fsck manually on it. Is there a way to automatically set it as RO and I'll check it after the server's up?
I read the fstab manual but didn't see any remount options.

Thank you.
 
You can try setting these:
Code: 
fsck_y_enable="NO"      # Set to YES to do fsck -y if the initial preen fails.
fsck_y_flags=""         # Additional flags for fsck -y
background_fsck="YES"   # Attempt to run fsck in the background where possible.
Set fsck_y_enable to YES and background_fsck to NO. Hopefully that will be enough to do a complete scan before the system fully boots.
 
Thank you, SirDice.

I've implemented the changes, hopefully it will fix my issue.
Waiting for the next power failure now...
 
If you have regular power outages it may be worthwhile to invest in a small UPS. The corruption could get worse and worse until you start losing data. The UPS can help cover short power outages and for longer ones it'll be able to signal to the FreeBSD machine to shutdown cleanly (before the battery of the UPS runs out).
 
Hello,
Thank you for the care. I really appreciate it.
The thing is that I had an UPS that burned out. It won't even power on. I ordered an APC Smart-UPS 3000VA 2700W 2U which will get delivered somewhere next week, but I wanted to be covered until then because we need to change the electrical installations a bit and power failures are quite often this few days.
I appreciate your help. Thank you!
 
Obviously, a UPS and orderly shutdown is 99% of the right answer.

A potential 1% solution would be to use a file system that is particularly tolerant of unclean shutdown. If you are using UFS, have you enabled soft updates? It supposedly helps to make sure the file system is consistent in spite of a crash (after a quick and painless fsck), but at a cost: the file system may be in an out-of-date state. Does your application handle files being out-of-date? What happens if there is suddenly a gap in the pflog files? For example, if the gap is not at a line boundary, but in the middle of a line? Does the program that reads and processes these logs know how to deal with that?

Nasty option: In fstab, mark the partition (= file system) as not automatically mounted. Like this it will not be mounted immediately at boot time. Then write a new "service" (one of the things that goes into /usr/local/etc/rc.d), which manually runs fsck (with -y) and mounts the file system. Then find whatever other subsystems or services use that file system (you said pflog above), and modify their corresponding rc.d scripts to not start until your new service with fsck is done, using the "require" and "provide" keywords. The cost of this option is: The service you really want doesn't start until later.

Do you need to worry about what happens if fsck fails (if the file system is too damaged) ??? I don't know what happens when rc.d scripts fail, and how that interacts with the "provide" and "require" mechanism.
 
ralphbsz said:
Nasty option: In fstab, mark the partition (= file system) as not automatically mounted. Like this it will not be mounted immediately at boot time. Then write a new "service" (one of the things that goes into /usr/local/etc/rc.d), which manually runs fsck (with -y) and mounts the file system. Then find whatever other subsystems or services use that file system (you said pflog above), and modify their corresponding rc.d scripts to not start until your new service with fsck is done, using the "require" and "provide" keywords. The cost of this option is: The service you really want doesn't start until later.
Click to expand...
This is basically what the fsck_y_enable and background_fsck do but in a clean way. The background_fsck makes sure the fsck(8) is completed before booting further. Normally any other filesystem besides / is checked in the background (and therefor can't fix things, only alert) while the system continues to boot. The fsck_y_enable makes sure you're doing a full check when the initial "preen mode" check failed. Because the fsck(8) is forced to complete before the system boots further it will take slightly longer for the system to boot completely.

I don't know what happens when rc.d scripts fail, and how that interacts with the "provide" and "require" mechanism.
Click to expand...
It doesn't really do much besides providing an order to run things. If ScriptB requires ScriptA all it does is run ScriptA first. There's no guarantee anything actually succeeded or if ScriptA's daemon actually started.

Code: 
BUGS
     The ``REQUIRE'' keyword is misleading: It doesn't describe which daemons
     have to be running before a script will be started.  It describes which
     scripts must be placed before it in the dependency ordering.  For exam-
     ple, if your script has a ``REQUIRE'' on ``named'', it means the script
     must be placed after the ``named'' script in the dependency ordering, not
     necessarily that it requires named(8) to be started or enabled.
From rcorder(8).
 
There's no app to use the pflog files. Those are logs generated by the pf firewall. Still, if a fsck is run at boot time, it's all I need.

Thank you.
 
that's a lot of downtime, now? checking the drives...

why/what do you write pf logs for, anyway? i'm just curious...

i think the solution would largely depend on your needs...
 
No, it's not a lot of downtime but what if I'm not next to it....?
Because I need the logs in case of botnets, viruses and others. This BSD is nating for around 600PCs. I need to know, in case of problems, which PC is to blame.
 
You must log in or register to reply here.
Back
Top