Reboot required after update for patches to be used?
-
I've tested quite a few patches and never noticed that they did not get applied until the first reboot after updating. I noticed that just now because the patch to fix the startup of unbound does not work the first time pfsense reboots after updating. After the first reboot, the patch is applied and works every time thereafter. I noticed on the console that the last thing that happens before the boot process is finished that packages are loaded. Since patches are handled by the patch package, this behavior is not a surprise. I'm wondering why I didn't notice this before. Is it a new feature?
-
Patches are applied as soon as you click the button to apply them.
Now whether or not the code in the patch will be run is up to whatever the patch is patching. If it patches a routine that only happens at boot time, or when a service is saved/applied, or when a WAN goes down/up, it will happen when the patched code is run.
-
Patches are applied as soon as you click the button to apply them.
Now whether or not the code in the patch will be run is up to whatever the patch is patching. If it patches a routine that only happens at boot time, or when a service is saved/applied, or when a WAN goes down/up, it will happen when the patched code is run.
Thank you for the reply. I'm not quite clear about this. If I apply a patch, does it stay applied when pfsense is updated or does it have to be "reapplied" by the patch package when the system boots the first time after the update?
Normally, when I test a patch, if it's robust, I usually set it to automatically apply. I've never noticed a patch set to automatically apply not getting "reapplied" after an update until after the first reboot. Perhaps I just didn't notice this was happening. The particular patch I'm referring to is PR #3799, which changes /etc/rc.newwanipv6, /etc/inc/services.inc and /etc/inc/interfaces.inc. I was noticing that after an update, I had to do another reboot before this patch worked. After that it worked every reboot. Now that the PR has been committed, it just works. I previously tested other patches to interfaces.inc, but did not notice this behaviour. Has it always worked this way?
-
The patch stays on a reboot, as it has already been applied to the *.php and *.inc files, if those were what was patched.
When you snapshot, the patched files are overwritten, so unless you have ticked the Auto-apply button then the patch is not applied and you revert to the un-patched file.
Does that make sense?
Regarding patch #3799 you no longer need it anyway, so delete it.
-
@marjohn56:
The patch stays on a reboot, as it has already been applied to the *.php and *.inc files, if those were what was patched.
When you snapshot, the patched files are overwritten, so unless you have ticked the Auto-apply button then the patch is not applied and you revert to the un-patched file.
Does that make sense?
Regarding patch #3799 you no longer need it anyway, so delete it.
Yes, that makes sense, but it's not what I saw happening, which is why I posted. As I said, this patch was set for auto apply, but for some reason, it did not appear to be applied on the first reboot after an update. On the second reboot, it was applied. This happened for multiple updates, so wasn't a one-time anomaly. I've never noticed that behaviour before, which is why I asked about it. I realize the patch is no longer required. I've already removed it.
-
Odd, did it say it had applied?
-
@marjohn56:
Odd, did it say it had applied?
Yes, odd. Yes, it said it had applied. It's strange, but I have no way to replicate it aside from reverting to a previous snapshot.
-
It may be a catch-22 it's in now. When you update, the package may not actually be present/active at the moment the shellcmd to apply patches wants to run at boot time. Not sure if we have any viable way around that at the moment.
-
It may be a catch-22 it's in now. When you update, the package may not actually be present/active at the moment the shellcmd to apply patches wants to run at boot time. Not sure if we have any viable way around that at the moment.
Yes, makes sense. Thanks for the info.
