Updates that do not require a reboot should run reroot
Hit a situation last night that seems like it might be rare but worth accounting for in the future: I updated a VM to test a change, but the update was base only and did not require a reboot. The previous copy of a page changed during the update had apparently been cached by the system and the updated page was not being presented to the browser. After restarting php-fpm it worked as expected. That should probably be done for any upgrade that touches the base pkg to be safe, and perhaps also restarting lighttpd would be a good idea.
Similarly, if it's not too hard to detect, it would be worthwhile to restart a daemon/service if it or one of its required dependencies is updated.
Add reroot support to system_reboot_sync() and to the /etc/rc.initial.reboot menu. Ticket #6045
#3 Updated by Renato Botelho over 3 years ago
- Subject changed from Updates that do not require a reboot should restart php-fpm/other services to Updates that do not require a reboot should run reroot
- Assignee set to Renato Botelho
- Target version changed from 2.3.2 to 2.4.0
All updates are requiring reboot nowadays while we didn't test reroot accordingly. IMO it's a big change for 2.3 series at this point and should be moved to 2.4
#6 Updated by Renato Botelho about 3 years ago
Jim Pingle wrote:
Doing a reroot style restart works nicely on its own, need to test it during an upgrade to know for sure how it handles that part.
If you want to try a reroot style upgrade, before run pfSense-upgrade just run:
# pkg unlock -g pfSense-kernel-\* # pkg upgrade -g pfSense-kernel-\*
This will remove kernel from the list of packages to be upgraded by pfSense-upgrade and then it will reroot
#7 Updated by Jim Pingle about 3 years ago
- Status changed from Feedback to Assigned
reroot crashes with ZFS. We will have to detect that case and fall back to a traditional reboot (or see if we can get the underlying FreeBSD bug fixed)
Fatal trap 12: page fault while in kernel mode cpuid = 7; apic id = 0e fault virtual address = 0x27103b0 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80c60ab4 stack pointer = 0x28:0xfffffe0236c36a60 frame pointer = 0x28:0xfffffe0236c36b10 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 5 (trim zroot)
db:0:kdb.enter.default> run lockinfo db:1:lockinfo> show locks No such command db:1:locks> show alllocks No such command db:1:alllocks> show lockedvnods Locked vnodes db:0:kdb.enter.default> show pcpu cpuid = 7 dynamic pcpu = 0xfffffe02a9caef00 curthread = 0xfffff80009e6ba00: pid 5 "trim zroot" curpcb = 0xfffffe0236c36cc0 fpcurthread = none idlethread = 0xfffff80006244a00: tid 100010 "idle: cpu7" curpmap = 0xffffffff829e5600 tssp = 0xffffffff82a1e0e8 commontssp = 0xffffffff82a1e0e8 rsp0 = 0xfffffe0236c36cc0 gs32p = 0xffffffff82a24940 ldt = 0xffffffff82a24980 tss = 0xffffffff82a24970 db:0:kdb.enter.default> bt Tracing pid 5 tid 100657 td 0xfffff80009e6ba00 _sx_xlock_hard() at _sx_xlock_hard+0x114/frame 0xfffffe0236c36b10 spa_config_enter() at spa_config_enter+0x63/frame 0xfffffe0236c36b70 trim_thread() at trim_thread+0xdc/frame 0xfffffe0236c36bb0 fork_exit() at fork_exit+0x85/frame 0xfffffe0236c36bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0236c36bf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
#8 Updated by Renato Botelho about 3 years ago
Looks like reroot doesn't work with ZFS without changing vfs.root.mountfrom