64 bit only – antiX-21-runit-beta2 available for testing.

Forum Forums antiX-development Development 64 bit only – antiX-21-runit-beta2 available for testing.

  • This topic has 222 replies, 22 voices, and was last updated Oct 16-7:40 am by Xecure.
Viewing 15 posts - 196 through 210 (of 222 total)
  • Author
    Posts
  • #67628
    Member
    olsztyn
    Helpful
    Up
    0

    BTW network-manager runit script is not included in runit-services-*

    I see it included in runit-services-…
    Aree you sure you have the latest version?

    #67630
    Forum Admin
    anticapitalista
    Helpful
    Up
    0

    I removed it from latest packages.
    Still, I suppose the upgrade ‘worked’ by not removing it from /etc/sv

    Philosophers have interpreted the world in many ways; the point is to change it.

    antiX with runit - leaner and meaner.

    #67632
    Member
    Xecure
    Helpful
    Up
    0

    However nm-applet is not coming up in tray. It is enabled in Session Startup.

    Make sure you installed network-manager-gnome

    antiX Live system enthusiast.
    General Live Boot Parameters for antiX.

    #67634
    Member
    olsztyn
    Helpful
    Up
    0

    Make sure you installed network-manager-gnome

    Thank you Xecure! My fault. I installed Network Manager, not gnome… Must have forgotten this detail since some time ago, installing last time…
    Greatly appreciate your pointing me to the correct one…

    #67639
    Member
    olsztyn
    Helpful
    Up
    0

    @ Xecure:
    Also, just to update on testing Connman error…
    Performed series of testing trying to narrow down and just providing these following observation and leaving conclusions to you, whether it is some kind of timing issue or it might be driver related.
    Specifically:
    – The original experience, where about 20% reboots were resulting in Connman error were testing on Core2Duo machine (Thinkpad X61), 2Ghz, 3G memory. Running antiX 21 B2 Live from internal HD (SATA). Running Live from HD was because it is the fastest execution and any remastering is very quick. Being Core2Duo it is not very powerful machine though, although perfect for antiX…
    – On the same machine (X61) running the same version antiX 21 B2, but this time Live from USB2 port stick, instead of from HD, resulted in far lower occurrence rate of Connman error, perhaps just 10% or lower, judging from multiple reboots. This is not scientific, but experience seems much more positive, running from slower device.
    – Tested the same antiX 21 stick in much more powerful i5 machine (Thinkpad T410) – I could not reproduce exactly the same Connman error so far, but after multiple times of successful connection, although no Connman error but occasionally (rarely) it does not connect on time and displays CMST as not connected although connection marked as Favorite. Leaving this CMST alone, not manually forcing to connect results in Connman eventually connecting to the Favorite by itself.
    I have not noticed such behavior with antiX 19, although I have not done such extensive ‘stress’ testing.

    Ones I get some more time I will test with Network Manager, so thanks again for the info…
    Regards.

    • This reply was modified 3 weeks, 3 days ago by olsztyn.
    #67678
    Member
    olsztyn
    Helpful
    Up
    0

    I will test what I did wrong with the connman, as there needs to be a reason for it to fail. And if this service fails occasionally, then the network.manager service will also fail occasionally.

    Well, it looks like (surprisingly!) this has not happened…
    Reporting the results of my testing and leaving conclusions to you:
    – I installed Network Manager to replace Connman on the same machine (X61), where Connman was failing to connect network in about 20% of cases.
    – Performed (time consuming) testing, rebooted total of more than 30 times, checking the state of WiFi connection after each boot. The result of this testing is that there was not one case where Network Manager failed to connect upon reboot on the machine where Connman was faling about 20% of cases (to be conservative).
    My interim conclusion:
    – The driver appears to not be the culprit (to answer the question by anticapitalista) for Connman failure to connect in about 20%, since it is the same driver is in place, whether you use Connman or Network Manager.
    – I would be cautious and not jump to conclusion to declare that Network Manager is more solid and reliable than Connman for antiX 21. I trust the issue with Connman will be fixed, even if it might affect just a minority of users.

    My time consuming testing was driven by curiosity, not to prove any preference for either Connman or Network Manager. Personally I hope the perceived (as in these tests) instability of Connman will be eventually fixed. Connman appears to save a few Kb of memory comparing to Network Manager, after all…
    Although I opted for Network Manager in my older antiX 19.2 instances (which worked for me more reliably than Connman at that time) I switched to Connman for antiX 19.4 – again to test).
    I am aware that Connman has been decreed by antiX’ owner as the one to use. Network manager is not. So I am trying to adapt to this ruling…

    Thanks again Xecure for your amazing level of help…
    Greatly appreciated.

    #67685
    Moderator
    Brian Masinick
    Helpful
    Up
    0

    @olsztyn: I see another parallel:
    I’ve had pretty good results with Connman, EXCEPT when I use Thinkpad hardware, in this case, the Thinkpad X201.

    The hardware is excellent but it’s difficult to keep the network up, especially with Connman. I think it’s a hardware support issue because Connman works much better with my Dell Inspiron 5558; I rarely have issues when I use that hardware.

    Brian Masinick

    #67697
    Member
    Xecure
    Helpful
    Up
    0

    @olsztyn
    So, you have confirmed that on your computer it does happen with connman but not with network manager.
    Thanks for the tests.

    Maybe the connman network check should be set at the same lower place in the startup script. If you don’t mind, could you move the network check below the nm-applet command in startup, switch again to connman, and see if the same error appears? If the issue was with the startup order, it would be a great relief. (I know this is very boring and time consuming, so if you don’t feel like it, it is OK).

    On my tests, connman worked on every test (though I a running live from USB 2.0). I will try installing on SSD and rebooting a few times, just to see if it because SSD is too fast that connman service didn’t start up before the network check command pops up.

    antiX Live system enthusiast.
    General Live Boot Parameters for antiX.

    #67710
    Member
    olsztyn
    Helpful
    Up
    0

    Maybe the connman network check should be set at the same lower place in the startup script. If you don’t mind, could you move the network check below the nm-applet command in startup, switch again to connman, and see if the same error appears?

    I will be glad to do it, in order to dig to the bottom of this Connman issue…
    Can you tell me how to properly change the startup order, to move network check below nm and to display the sequence to make sure it is in the expected order?
    Thanks and Regards…

    #67711
    Member
    Xecure
    Helpful
    Up
    0

    I will be glad to do it, in order to dig to the bottom of this Connman issue…

    Thanks.

    Can you tell me how to properly change the startup order, to move network check below nm and to display the sequence to make sure it is in the expected order?

    It is as you say. nm-applet entry in the startup script is the last item (or one of the last). If you move the network-check-antix or the network-readiness command (only one of them, the other leave it disabled) just below nm-applet (and disable nm-applet), then reboot (after enabling connman and disabling network-manager service), we can see if the error occurs on your system when it launches so late in the startup process.

    Hopefully this is the reason for the error, and not something else. If you still experience this, then cmst isn’t the problem, but the configuration of the connman service.

    antiX Live system enthusiast.
    General Live Boot Parameters for antiX.

    #67725
    Member
    olsztyn
    Helpful
    Up
    0

    It is as you say. nm-applet entry in the startup script is the last item (or one of the last). If you move the network-check-antix or the network-readiness command (only one of them, the other leave it disabled) just below nm-applet (and disable nm-applet), then reboot (after enabling connman and disabling network-manager service),

    OK. So you mean Session Startup, and not Runit service startup sequence, which I initially misunderstood you wanted me to change?… This is much simpler.
    So I performed the following. Just to make sure:
    – Moved network-check-antix & to the level just below nm-applet.
    – Disabled start of nm-applet
    – Stopped NetworkManager service and disabled startup on boot. Status Down.
    – Started Connman service and enabled startup on boot. Status Up.

    Having done the above config I remastered. I do not use any persistence for reliability. Rebooted total of over 30 times checking of state of Connman connecting network.
    The result of test with this configuration does not make any sense to me:
    – At first Connman connected network just fine. It was not until about boot #12, when it failed to connect. The difference now however was that unlike the original failure no ‘CMST Error’ window popped up. Just no network.
    – Continued rebooting. Connman was connecting network just fine for some reboots until it failed again connecting network without CMST error message, just as above. Now Connman failure to connect became more frequent and even several failures in sequence. Each time with no ‘CMST Error’ message popping up.

    This does not make sense to me at all, as the only difference in configuration was moving network-check-antix to much lower position in Startup sequence…
    So I want to make sure if the above config change was supposed to be the only thing you wanted me to change or there is something else (or in addition), such as service config?
    Thanks and Regards…

    • This reply was modified 3 weeks, 2 days ago by olsztyn.
    #67730
    Member
    olsztyn
    Helpful
    Up
    0

    @ Xecure:
    I have been trying to perform more testing to determine some more details of this behavior and just noticed that each time Connman fails to connect network in this current configuration, the Connman service is Down. Since Startup is Up, it comes back up upon reboot and connects network, unless it fails again in sequence, but that seems to be not too frequent.
    This is just to add to my observations…

    UPDATE!!!
    Double checking all pieces I just found the reason why ‘CMST – Critical Error’ was not popping up when Connman failed during recent testing, which did not make sense to me: Inadvertently I had ‘network-check-antix) &’ instead of ‘network-check-antix &’ as I copied to below nm-applet. This was left from network readiness check loop, which I failed to notice at first…
    So to correct my original report, as confirmed by my subsequent testing:
    – ‘CMST – Critical Error’ message with the previously reported content ‘Unable to create an interface to connman on the system bus. CMST will not be able to communicate with connman.’ does in fact pop up properly, when Connman fails to connect network.
    – Each time Connman fails to connect network I found that Connman service is Down.

    I apologize for the confusion about CMST message not popping up. This mystery bugged me so I had to dig into the cause…
    So it appears after all this testing that moving ‘network-check-antix &’ to much later, below nm-applet, did not make a difference for the Connman behavior in connecting network, except confirmed that Connman service is Down when it happens.
    Thanks and Regards…

    • This reply was modified 3 weeks, 2 days ago by olsztyn.
    #67742
    Member
    Xecure
    Helpful
    Up
    0

    @olsztyn

    I got the error to pop up at last. I updated and installed in a new partition a21b2-runit and, after about 10 reboots (between normal reboots, shutdownsbooting to other antiX installations, etc.), I could see the error. Luckily I have set up logs for both dbus and connman and saw that connman failed to start because it couldn’t confirm that dbus was running. I think there is a bug in the runit implementation of debian-devuan (which antiX’s version of runit inherits a lot from), that makes checks be very impatient. I also see this happen when I activate a service wth the runit-service manager. I add a new service, and even when I send the signal to rescan the /etc/service folder, it still soetimes takes longer to properly rescan and start the service (and the GUi cannot show that the service started properly).

    It seems that, connman (alphabetically) starts first, before dbus. When connman calls for it to start (because it hasn’t yet), it normally starts dbus properly, but sometimes dbus takes so long to start that runsv informs connman that dbus cannot start and connman service stops abruptly. Because I have it set up to not persist and stop if dbus service doesn’t exist or is disabled (so it doesn’t error out and continuously log those errors and write to disk), connman stops and you cannot connect to the internet.

    I have seen in my elogind logs that the same happens for it if I disable connman (though alphabetically comes after dbus), so this isn’t only a connman issue.

    Network manager is so “far” down the order of services starting that dbus is already properly started when network-manager asks for it.

    I will explore a non-specific antiX check for dbus. Meanwhile, could you edit the /etc/sv/connman/run file so it looks like this:

    #!/usr/bin/env /lib/runit/invoke-run
    set -e
    
    NAME="connman"
    DAEMON=/usr/sbin/connmand
    
    # Exit service if DAEMON is not installed
    if [ ! -x $DAEMON ]; then
    	exit 161
    fi
    
    # Start dbus first
    sv start dbus
    sv status dbus && sv check dbus  ||  exit 170
    
    # Load defaults
    [ -f /etc/default/connman ] && . /etc/default/connman
    
    exec 2>&1
    
    exec $DAEMON -n ${OPTS}

    antiX Live system enthusiast.
    General Live Boot Parameters for antiX.

    #67749
    Member
    olsztyn
    Helpful
    Up
    0

    I will explore a non-specific antiX check for dbus. Meanwhile, could you edit the /etc/sv/connman/run file so it looks like this:

    Looks like you got to the bottom of this Connman issue… It makes perfect sense now why Network Manager starts each time and Connman fails sometimes…
    I will edit the /etc/sv/connman/run file per the above.
    Thanks and Regards.

    • This reply was modified 3 weeks, 2 days ago by olsztyn.
    #68096
    Member
    olsztyn
    Helpful
    Up
    0

    I got the error to pop up at last. I updated and installed in a new partition a21b2-runit and, after about 10 reboots (between normal reboots, shutdownsbooting to other antiX installations, etc.), I could see the error. Luckily I have set up logs for both dbus and connman and saw that connman failed to start because it couldn’t confirm that dbus was running. I think there is a bug in the runit implementation of debian-devuan (which antiX’s version of runit inherits a lot from), that makes checks be very impatient. I also see this happen when I activate a service wth the runit-service manager. I add a new service, and even when I send the signal to rescan the /etc/service folder, it still soetimes takes longer to properly rescan and start the service (and the GUi cannot show that the service started properly).

    @ Xecure:
    Just to confirm, as you expected: Your adjustment above, to /etc/sv/connman/run:

    # Start dbus first
    sv start dbus
    sv status dbus && sv check dbus || exit 170

    does resolve this connman issue in practice. Since that adjustment This issue has never occurred since.

    Thanks and Regards…

Viewing 15 posts - 196 through 210 (of 222 total)
  • You must be logged in to reply to this topic.