These issues are reported from time to time. But most systems upgrade without problems ( from the WUI!!!).
Without knowing the configuration of the systems with issues, it is difficult to guess the reason for the problem.
It could help also, if those systems are upgraded on the test branch. This isn’t recommended for production systems, but maybe some systems can used anyway.
Well, it shouldn’t really be a problem to finally implement the process of restarting Apache at the end of each update and checking that it is running.
The problem has been happening very often in the last few updates. It really should be taken seriously.
2 Likes
A restart of Apache is in the Core Update 185 update.sh script.
Core Update 185 update.sh script
See line 92 in that update script for the line that restarts apache.
This is even though no change was made to apache in CU185 so nothing should have stopped it anyway.
If it is believed that the frozen WUI page is because of apache not working then this should be checked by running, on the console, the command
/etc/rc.d/init.d/apache status
This will then confirm if apache was stopped or not?
Someone earlier in this thread mentioned that the core update log had
If that is the last line after the update was running for more than several minutes then the update got stopped part way through.
Apache not running would not stop the upgrade occurring, only being able to access the WUI.
That makes me suspect that whatever is being experienced is not down to apache.
In the four systems I have updated (plus also during the Testing Phase when I evaluated the update on three of my systems) I had no freezing of the WUI. The update took around 2 mins 30 secs to 3 mins to successfully complete in all cases.
2 Likes
For me, too, after upgrading from version 184 to 1, pakfire hung up on the update. The web interface became unavailable, but the rest of the functions continued to work. I didn’t have time to turn on SH, as I had just installed the firewall. Also, in the new version, after updating to 185, there were problems with the asus pce-n15 wi-fi adapter. With some devices, it simply does not connect, and with others, the speed is simply minimal. It is enough to return version 184 and everything is fine.
I have the same assumption. However, the question then arises as to why the update was completed correctly after a hard reboot and Apache is running normally again.
So maybe a way should be found to restart Apache independently of this process, even if the update somehow doesn’t reach the end.
Btw. Apache was not really restarted at the end in the update script. For example, I noticed that suricata worked for a very long time after the update. No idea if this has affected the restart of Apache at the end.
I have just checked the logs and found that the message
is only shown on the WUI screen. It is not fed into the core update log. So if the WUI screen froze then that was the last message that was shown before it froze.
To check if the upgrade completed or not you would need to look at the end of the
/var/log/pakfire/update-core-upgrade-185.log
file.
If it finishes with
Generating grub configuration file …
Found linux image: /boot/vmlinuz-6.6.15-ipfire
Found initrd image: /boot/initramfs-6.6.15-ipfire.img
Adding boot menu entry for UEFI Firmware Settings …
done
then the update completed successfully, including the restart of apache.
It would be good to have confirmed from someone that had the frozen WUI screen if apache was or was not running after the screen had frozen.
1 Like
I am not sure what you mean by the above statement.
In my update-core-upgrade-185.log I have the following lines
Stopping SSH Server…
e[1Ae[0Ge[-8Ge[1;34m[e[1;32m OK e[1;34m]e[0;39m
Starting SSH Server…
e[1Ae[0Ge[-8Ge[1;34m[e[1;32m OK e[1;34m]e[0;39m
Restarting Apache daemon…
e[1Ae[0Ge[-8Ge[1;34m[e[1;32m OK e[1;34m]e[0;39m
Stopping Intrusion Detection System…
e[1Ae[0Ge[-8Ge[1;34m[e[1;32m OK e[1;34m]e[0;39m
Starting Intrusion Detection System…
e[1Ae[0Ge[-8Ge[1;34m[e[1;32m OK e[1;34m]e[0;39m
Stopping Unbound DNS Proxy…
e[1Ae[0Ge[-8Ge[1;34m[e[1;32m OK e[1;34m]e[0;39m
Starting Unbound DNS Proxy…
e[1Ae[0Ge[-8Ge[1;34m[e[1;32m OK e[1;34m]e[0;39m
Setting time on boot…
e[1Ae[0Ge[-8Ge[1;34m[e[1;32m OK e[1;34m]e[0;39m
Starting ntpd…
e[1Ae[0Ge[-8Ge[1;34m[e[1;32m OK e[1;34m]e[0;39m
Creating Squid swap directories…
e[1Ae[0Ge[-8Ge[1;34m[e[1;32m OK e[1;34m]e[0;39m
Starting Squid Proxy Server…
e[1Ae[0Ge[-8Ge[1;34m[e[1;32m OK e[1;34m]e[0;39m
Stopping Collection daemon…
e[1Ae[0Ge[-8Ge[1;34m[e[1;32m OK e[1;34m]e[0;39m
e[1Ae[0Ge[-8Ge[1;34m[e[1;32m OK e[1;34m]e[0;39mStarting Collection daemon…
e[1Ae[0Ge[-8Ge[1;34m[e[1;32m OK e[1;34m]e[0;39m
The peculiar characters are just because of a coding difference.
You can see that Apache was successfully restarted followed by suricata, they both got an OK response, as did everything else in my update.
What do these lines show in the log file for the case when the WUI screen froze.
For the users who have experienced the frozen WUI was the upgrade being done from CU184 to CU185 or from earlier than CU184.
1 Like
This brings me to a suspicion. How are the systems with issues connected to the WUI? By ethernet or by wifi?
From 184 to 185 - over LAN.
So that removes the possibility that the issue is due to more than one step in the core update or that the connection is by wifi adapter.
I think we need to see what is in the
/var/log/pakfire/update-core-upgrade-185.log
file for users that had the frozen WUI to compare it with what is in the log for users that had no issue. Hopefully there will be some info to give a clue as to what is happening.
1 Like
Here’s the tail of my log:
It indicates the process completing, yet WUI hung on the pakfire page. I was still able to go to the System tab in WUI and do a clean reboot. The many people who are doing a hard reboot don’t need to.
It was on a computer that is available only directly from China and goes under various brand names, that might all have the same UEFI. My brand is BEBEPC, FWIW.
I run an Asrock mainboard, with AMD 5350 APU, for the testing branch. It had completed the upgrade with a WUI message from pakfire, to the effect, “your system requires a reboot”
My reserve operational IPF also runs on a mini-PC of obscure name. It has an AMD A6-1450 APU and also completed with a WUI message from pakfire, to the effect, “your system requires a reboot”
1 Like
Thats not true.
Firefox showed me an empty page and thats it.
Only reboot over ssh works.
In that case, this is another variable, namely web browser. I routinely use Falkon to access the WUI, although I do regularly use Firefox for some other URL.
Hi.
Of the 4 IPFires that I have updated, all 4 I have had problems and it turns out that those 4 are from PCEngines APU.
I’m not saying that there haven’t been people who haven’t had problems, but I have had 100% of the updates.
I’ll try doing the updates via SSH.
Saludos.
1 Like
Because the PCEngine APU systems are kind of reference devices, I can’t believe that it is caused by this HW.
There must be some ‘special’ configuration causing the issue. But we cannot guess that. It should be delivered by users with those problems.
Hi @bbitsch.
I just tried updating a PCEngines using SSH and here is the example:
SSH says it’s done, but the WUI is frozen.
When I run Apache restart it says it is not running.
[root@bs ~]# /etc/init.d/apache restart
Stopping Apache daemon...
httpd (no pid file) not running [ OK ]
Starting Apache daemon... [ OK ]
[root@bs ~]#
This is the hardware:
https://fireinfo.ipfire.org/profile/7449e75da4fbd1af8bb016281fcb790e9e19e8d7
The configuration is standard. It doesn’t have any “rare” modifications.
Saludos.
1 Like
Your system is nearly identical to mine
https://www.ipfire.org/fireinfo/profile/22c8277aa27925ec2cfd9585a56049278e11af9
Main difference is the wifi card and the orange zone.
Will it help if i post my HW-Info?
https://www.ipfire.org/fireinfo/profile/0f09665665715f5c24fe6e6a886167a15121e130
And by the way: Some entries at the HW-Info are wrong.
My SSD has only 500GB and not 1TB 
@rodneyp can you show all the restart section. The bit you show is after the apache restart section.
The restart section starts with Stopping SSH server...
Do I understand you correctly that the WUI pakfire page froze but the menu still allowed you to change to the System tab and reboot the system from the WUI? If that is so then that is different to what other users have mentioned on this thread.
With all my IPFire instances it is always Firefox that I am using for the browser.
@roberto can you please show the restart section of your
/var/log/pakfire/update-core-upgrade-185.log
starting from the line Stopping SSH server...
I want to see if the apache restart had a problem causing it not to be running at the end of the update or if the apache restart worked in the update and something else caused apache to stop working later in the update process.
What browser are you using to access the WUI on your IPFire systems?
2 Likes
Your message you get with apache restart when it is not working is different to what I get when I run the same command via my ssh terminal.
[root@ipfire ~]# /etc/init.d/apache restart
Restarting Apache daemon…
httpd not running, trying to start [ OK ]
As we are both on Core Update 185 we should get the same message response.
What happens if you now stop apache from your ssh terminal using
/etc/init.d/apache stop
it will take a while to stop.
Then run your restart command again. Do you get the same as you got previously or the same as I got. This should show if the different message is consistent or was caused by the problem during the update.
1 Like