To schedule a reboot
-
I'm again on the argument…
As the filesystem is read only, I cannot modify /etc/crontab unless I issue the command :
/etc/rc.conf_mount_rw
So I can modify the crontab file
Anyway all modifications to crontab are lost at the next reboot
Why is this ?
Is there a way to write a file permanently on disk (an alixboard with compact flash in this case)Thank you very much for any help
-
What version are you on? Nano is now read/write by default. If you are making manual edits to crontab, try installing the Cron package, and making changes via that.
-
I'm on a 2.0.3 (i386)
No cron package is listed in GUI available ones….
-
I'm on a 2.0.3 (i386)
No cron package is listed in GUI available ones….
I don't think anyone is going to be able to help you unless you move to a more recent version…
-
I'm a little amazed that soooooooooooooo many people ask for this feature and its still not a simple setting in pfsense.
You would think this is one of those features that could be created in 15 minutes while drinking heavily and eating with one hand.
-
Hummm.
They guy that does code with one hand, doing other things with the other, is coding right now …..
But surely not for 2.0.3 ....... -
Scheduling a reboot is an awful practice. To encourage it would be just as awful. The firewall should never have to reboot.
The cron package exists for people who want to schedule things like that manually. Get on a current version and there will not be a problem.
-
Since pfSense is based on FreeBSD there is the at(1) command that is designed just for one time execution of a specific task at a specific time.
-
@kpa:
Since pfSense is based on FreeBSD there is the at(1) command that is designed just for one time execution of a specific task at a specific time.
I haven't tried on 2.3 but on 2.2 the at command did not work because we didn't include all of its requisite pieces.
-
Sometimes you just should give the customers what they are asking for and print a disclaimer on the product…
-
Does direct XML editing not work anymore? I've used it for years without any cron package installed.
<minute>1</minute> <hour>1</hour> <mday>*</mday> <month>*</month> <wday>*</wday> <who>root</who> <command></command>/usr/bin/nice -n20 /etc/rc.dyndns.update -
"Sometimes you just should give the customers what they are asking for and print a disclaimer on the product…"
Sometimes ok when the customers are paying ;) If they want this feature put up a bounty! What I just can not understand is why is somebody still running 2.0.3?? And they are trying to debug something?? How about just move to current and its quite possible whatever your trying to debug has already been fixed or is no longer a problem, etc.
Quite often the "customer" in these cases are just not understanding the product, and asking for shit that has no use case for the 99% of the other customers that do.
I'm also with jimp on the scheduled reboot - that in general is a horrific idea that should be avoided at all cost.. Why would you want to reboot your firewall?? I can see it as necessary evil on some updates, like moving to current freaking version ;) Patches at the kernel level, etc. But in general the only time your firewall or really any system used in production should have to reboot is on some form of update to the system at a very low level. Security patch, os update, etc.
-
Yeah - I don't reboot mine either except in the cases that you mentioned. Still, alot of people do ask for it and alot of people get it, but not the easy way.
-
A lot of people ask for it, but very nearly zero actually need it. It's a solution without a real problem. It would confuse people who think they need it when they don't.
If someone really needs it, it's a few clicks to add a cron job on a current version with the cron package. End of story.
If they're on an old version they could hand edit config.xml but they should also not be on an older version.
-
I would love to hear an actual use case that made sense for a scheduled reboot.. I can understand a scheduled standing maintenance window where you were allowed to take the system offline for a bit. This is when you would do your upgrade that requires reboot, hardware upgrade/maint, new/change wiring, etc.
I am curious to what sort of debugging needs a scheduled reboot as well??
-
Sometimes you just should give the customers what they are asking for and print a disclaimer on the product…
The customer is not always right. That's called selling out. I've never had issue calling out bad ideas in my line of work. Most people appreciate my frankness. Of course if someone twists my arm, I'll give, but only have explicit warning that I take no responsibility for any issues that arise and if someone calls complaining their world is on fire Friday at 4pm, they're waiting until Monday morning. A few times I had to work weekends. But if I'm working 2 hours on Saturday, I'm taking all of Monday off and that will not count against my vacation time.
A professional has a duty to make sure they don't enable customers to harm themselves.
-
OK - So situation where the the evil scheduled reboot would have been useful. I have a pfsense running in Florida.
It is the router for a friend but its also backup personal use VPN for me. Went to use it because of a rare major outage caused by a storm recently took my main pfsense offline for 2 days.
There was no one at the place in Florida to reset or reboot the machine but it was not able to be contacted by me from here.
When someone was able to get to my machine, 2 days later (2 days too late), the internet was fine and it was routing fine.
Apparently no problems right? What happened is the WAN IP changed and DNS was not dynamically updated as it should have been.
A simple reboot fixed it.
Now, it would be no inconvenience at all for anyone for this machine to reboot nightly at 4am.
I know the real problem here was with the DNS not updating and if I geeked around enough I might be able to figure out some hack to make it more reliable.However - A reboot is so much more simple in this case.
Its not best practice most of the time, but sure would have saved me some headaches this time.
Also, I didn't invent the concept of having GUI options for scheduled reboots. It was on other routers.Had the same issue with DD-WRT in the past and having it reboot kept it from being offline and uncontactable for days on end also.
It was a mild aggravation at times for the few seconds it would go down and come back up but at least it wasn't gone for days on end. -
I just found a reason why I have to schedule reboot the firewall.
We having a problem today as pfSense corrupted, after reinstall and restore from backup config, people from outside access (for example VPN) seems very slow. But I can't simply restart it in day time, I need a reboot at 12am, and I want go to bed early :'(
-
A reboot only masks the issue, It would be better to solve it
-
I've done it, several times. I've set up a crontab from an ssh shell:
30 06 * * * /sbin/shutdown -r now
to reboot the firewall at 6:30 each morning. It seems to stick just fine until it's physically removed, and I've used it on several v2 versions, though I can't say specifically that I've done it on 2.0.x
