Created attachment 929 [details] avahi error message when trying to start avahi fails to successfully start giving the error log message in the attached file. The message was highlighted from https://community.ipfire.org/t/trouble-when-upgrading-from-core-157-to-core-158/5842 I have confirmed the same result if I try to install cups (avahi as dependency) or if I try and just install avahi on its own.
Could you try restarting dbus and then starting avahi again? It looks like it didn't read Avahi's policy file.
Not sure how to restart dbus. There is no init.d file for it. I have found additional dbus related error in the logs which I have also attached.
Created attachment 930 [details] dbus-daemon errors
(In reply to Adolf Belka from comment #2) > Not sure how to restart dbus. There is no init.d file for it. It is called /etc/init.d/messagebus. This looks like the classic permissions problem that some people have after installing updates. Could you please send the output of these commands: > stat /etc > stat /etc/dbus-1 > stat /etc/dbus-1/system.conf > stat /usr > stat /usr/share > stat /usr/share/dbus-1 > stat /usr/share/dbus-1/system.conf
(In reply to Michael Tremer from comment #4) > (In reply to Adolf Belka from comment #2) > > Not sure how to restart dbus. There is no init.d file for it. > > It is called /etc/init.d/messagebus. > > This looks like the classic permissions problem that some people have after > installing updates. Could you please send the output of these commands: > > > stat /etc File: /etc Size: 4096 Blocks: 8 IO Block: 4096 directory Device: 804h/2052d Inode: 1310721 Links: 53 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2021-07-20 15:00:50.554573180 +0200 Modify: 2021-07-20 14:56:45.497904957 +0200 Change: 2021-07-20 14:56:45.497904957 +0200 Birth: 2020-12-07 12:27:49.946667214 +0100 > > stat /etc/dbus-1 File: /etc/dbus-1 Size: 4096 Blocks: 8 IO Block: 4096 directory Device: 804h/2052d Inode: 1311520 Links: 3 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2021-07-20 14:39:11.321002675 +0200 Modify: 2021-07-15 21:52:26.000000000 +0200 Change: 2021-07-20 14:19:39.664328570 +0200 Birth: 2021-01-18 10:01:32.895744252 +0100 > > stat /etc/dbus-1/system.conf File: /etc/dbus-1/system.conf Size: 833 Blocks: 8 IO Block: 4096 regular file Device: 804h/2052d Inode: 1317138 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2021-07-20 15:22:43.604581517 +0200 Modify: 2021-02-22 22:45:22.000000000 +0100 Change: 2021-07-20 14:19:36.304328548 +0200 Birth: 2021-07-20 14:19:36.304328548 +0200 > > stat /usr File: /usr Size: 4096 Blocks: 8 IO Block: 4096 directory Device: 804h/2052d Inode: 1572866 Links: 10 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2021-07-20 14:48:33.631006245 +0200 Modify: 2021-07-15 21:52:26.000000000 +0200 Change: 2021-07-20 14:19:40.140995239 +0200 Birth: 2020-12-07 12:28:06.556667321 +0100 > > stat /usr/share File: /usr/share Size: 4096 Blocks: 8 IO Block: 4096 directory Device: 804h/2052d Inode: 1581142 Links: 30 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2021-07-19 02:47:00.800320713 +0200 Modify: 2021-07-15 21:52:27.000000000 +0200 Change: 2021-07-20 14:19:40.140995239 +0200 Birth: 2020-12-07 12:28:20.930000745 +0100 > > stat /usr/share/dbus-1 File: /usr/share/dbus-1 Size: 4096 Blocks: 8 IO Block: 4096 directory Device: 804h/2052d Inode: 1707124 Links: 7 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2021-07-19 02:47:00.846987380 +0200 Modify: 2021-02-22 23:56:03.000000000 +0100 Change: 2021-07-20 14:19:36.307661882 +0200 Birth: 2021-01-18 10:01:32.895744252 +0100 > > stat /usr/share/dbus-1/system.conf File: /usr/share/dbus-1/system.conf Size: 5696 Blocks: 16 IO Block: 4096 regular file Device: 804h/2052d Inode: 1707201 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2021-07-20 15:22:43.604581517 +0200 Modify: 2021-02-22 22:45:22.000000000 +0100 Change: 2021-07-20 14:19:36.304328548 +0200 Birth: 2021-07-20 14:19:36.304328548 +0200
These all look good. Any user is allowed to read those configuration files. Are there some files named "avahi" somewhere in /etc/dbus-1?
Running status I get lots of lines of the following /etc/rc.d/init.d/functions: line 332: shift: 2: shift count out of range Running start gets me the following Starting the D-Bus Messagebus Daemon... Unable to continue: /usr/bin/dbus-daemon is running Stopping messagebus and then starting again gets the following Starting the D-Bus Messagebus Daemon... /etc/rc.d/init.d/functions: line 366: kill: (15947) - No such process Unable to continue: /var/run/dbus/pid exists
(In reply to Michael Tremer from comment #6) > These all look good. Any user is allowed to read those configuration files. > > Are there some files named "avahi" somewhere in /etc/dbus-1? No. Only session.conf and system.conf together with a system.d directory
(In reply to Adolf Belka from comment #7) > Running status I get lots of lines of the following > > /etc/rc.d/init.d/functions: line 332: shift: 2: shift count out of range > > > Running start gets me the following > > Starting the D-Bus Messagebus Daemon... > Unable to continue: /usr/bin/dbus-daemon is running > > Stopping messagebus and then starting again gets the following > > Starting the D-Bus Messagebus Daemon... > /etc/rc.d/init.d/functions: line 366: kill: (15947) - No such process > Unable to continue: /var/run/dbus/pid exists Forgot tos mention that when I stopped messagedbus it cam up with a red FAIL status
Okay, so as bad as it looks, is it right that dbus is starting and running? Could you post /var/log/pakfire/*-avahi.log? Either from the install or update.
Created attachment 931 [details] install-avahi.log
Created attachment 932 [details] uninstall-avahi.log
These log files are from the install and uninstall of avahi on my 158 upgraded system.
That looks like those processes have been performed okay. But how do you have an uninstall log when you want the package?
I only ran the avahi install because the person on the forum had the problem of it failing to start. So I installed it, found the same problem, then uninstalled it and installed cups, which has avahi as a dependency but avahi still did not start. At the end I don't need avahi or cups on my system but I was just confirming if I also had the same issue.
Okay. I will have to reproduce on my own system them. I am using avahi and it seems to work fine there...
Okay, interesting results. With you not having the problem I thought I would try it out on some systems in my testbed vm. I had a core update 157 system. I installed cups and then was able to start avahi with no problems. Then I uninstalled cups and all dependencies, upgraded to 158 and installed cups again. This time avahi would not start and the error messages were as I previously had. I then thought I would try installing cups on a 157 system and then upgrade to 158 with cups and avahi in place and see if that made a difference. I installed cups on another 157 system but this time avahi would not start again with the same error message!!! Not sure if the experiments I had been doing had affected it. I will do a fresh install of 157 and install cups and if that can then start I will then upgrade to 158 with cups/avahi in place and running and see what happens.
Before I did a fresh install of 157 on a vm I rebooted the 157 vm that would not start avahi. I got error messages when closing down because IPFire failed to successfully shut down avahi. After rebooting avahi started automatically with no problem. I then upgraded to 158 and avahi was running and I could shut it down and turn it on again. I will re-install cups/avahi on my production system. Confirm the problem with starting avahi and then do a reboot and see if avahi then works.
Okay, I re-installed cups/avahi on my production system with the failures mentioned earlier. I confirmed that I could not start avahi. I got the same error messages. I then rebooted and after coming back up avahi was running. I could then turn it off and turn it on from the services page with no problems. It looks like if you already have avahi installed and running successfully on Core Update 157 and then upgrade to core update 158 there is no problem. Only if you install avahi on core update 158 then you have to do a reboot to get avahi successfully able to start and stop. I will do a fresh install of core update 157 on my vm and install avahi on that, confirm it is able to be started and stopped and then do the upgrade to 158 and see what the result is.
Fresh install of core update 157 and then installed cups/avahi. Could not start avahi. Rebooted and then avahi was running and I could successfully start and stop it. Then carried out upgrade to 158 and with no additional reboot avahi was running and could be successfully stopped and started. On my production system with core update 158 that I had got avahi working after doing a reboot - I then uninstalled cups/avahi and then after a while re-installed them. Avahi would not start again. A further reboot was required to make it start/stop again.
Just did a fresh install of core update 156 on my testbed vm and installed cups/avahi and was able to start and stop it. It looks like something happened from 156 to 157 that means that installing cups/avahi doesn't allow starting avahi without a reboot.
(In reply to Adolf Belka from comment #19) > It looks like if you already have avahi installed and running successfully > on Core Update 157 and then upgrade to core update 158 there is no problem. > Only if you install avahi on core update 158 then you have to do a reboot to > get avahi successfully able to start and stop. Restarting dbus should be enough. Thank you for confirming this and looking into it. I will submit a patch.
It has become three patches out of which these are relevant: * https://patchwork.ipfire.org/project/ipfire/patch/20210721144158.25747-2-michael.tremer@ipfire.org/ * https://patchwork.ipfire.org/project/ipfire/patch/20210721144158.25747-1-michael.tremer@ipfire.org/ I found the same problem in CUPS, so I fixed that, too: * https://patchwork.ipfire.org/project/ipfire/patch/20210721144158.25747-3-michael.tremer@ipfire.org/
I just cloned another Core Update 157 vm and updated it to 158 and tried again the installing of cups/avahi. I did this because on the community forum someone had highlighted permissions problems but also that they had the problem with starting avahi. They had flagged up that after fixing their permissions they also no longer had a problem with avahi starting. The permissions fix I understand has been applied to any update to 158 that occurs from now on. After installing cups/avahi on the freshly updated Core Update 158, I was able to start both cups and avahi on the services page without any need to do a reboot first. Also there are no longer any of the avahi messages in the logs. That was all without the patches that you have created so I am not sure if they are needed or not, although they probably won't hurt.
Arne just confirmed to me on the phone that he never ran into this problem either. It could simply be the order in which packages are being installed and if dbus has been installed before. They definitely won't hurt. Worst thing would be that we reload dbus.
Tested out installing avahi on its own and as part of a cups install on a Core Update 159 vm system. In bot cases avahi automatically started without and issues. Marking this bug as closed/fixed.