Hello @Eric. > What make Bionic more susceptible to this particular problem ? Bionic kernel version in use ? else ?
I believe klibc/ipconfig itself is susceptible to the problem in Bionic and Focal and elsewhere. However, Focal (which uses klibc 2.0.7) uses dhclient for networking initialization instead of ipconfig, therefore I am not really concerned about fixing the ipconfig issue in Focal since it is not causing any noticeable problems. I have checked the HEAD of the klibc project and it appears that ipconfig is still susceptible to the timeout problem. Sure I can propose the patch upstream if you like - however, even if they accept it I believe we will still need to apply it separately for Bionic because I do not expect that Bionic will receive any major updates for klibc, so it will not get any upstream fixes. It will remain on 2.0.4 as far as I know. It is currently version 2.0.4-9ubuntu2 in Bionic which means we are carrying (2?) Ubuntu-specific patches on top of 2.0.4. I believe this fix can be added as well to produce 2.0.4-9ubuntu3. I will attempt to upstream this fix to klibc, but I believe the change to Bionic should happen in parallel/independently since the upstream patch will not make its way back to Bionic (which is stuck at 2.0.4, as mentioned above). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to klibc in Ubuntu. https://bugs.launchpad.net/bugs/1947099 Title: ipconfig does not honour user-requested timeouts in some cases Status in klibc package in Ubuntu: New Status in klibc source package in Bionic: New Bug description: ** SRU TEMPLATE DRAFT ** [Impact] [Test Plan] [Where problems could occur] [Other Info] [Original Description] In some cases, ipconfig can take longer than the user-specified timeouts, causing unexpected delays. in main.c, in function loop(), the process can go into process_timeout_event() (or process_receive_event() ) and if it encounters an error situation, will set an attempt to "try again later" at time equal now + 10 seconds by setting s->expire = now + 10; This can happen at any time during the main event loop, which can end up extending the user-specified timeout if "now + 10" is greater than "start_time + user-specified-timeout". I believe a patch like the following is needed to avoid this problem: --- a/usr/kinit/ipconfig/main.c +++ b/usr/kinit/ipconfig/main.c @@ -437,6 +437,13 @@ static int loop(void) if (timeout > s->expire - now.tv_sec) timeout = s->expire - now.tv_sec; + + /* Compensate for already-lost time */ + gettimeofday(&now, NULL); + if (now.tv_sec + timeout > start + loop_timeout) { + timeout = loop_timeout - (now.tv_sec - start); + printf("Lowered timeout to match user request = (%d s) \n", timeout); + } } I believe the current behaviour is buggy. This is confirmed when the following line is executed: if (loop_timeout >= 0 && now.tv_sec - start >= loop_timeout) { printf("IP-Config: no response after %d " "secs - giving up\n", loop_timeout); rc = -1; goto bail; } 'loop_timeout' is the user-specified time-out. With a value of 2, in case of error, this line prints: IP-Config: no response after 2 secs - giving up So it thinks that it waited 2 seconds - however, in reality it had actually waited for 10 seconds. The suggested code-change ensures that the timeout that is actually used never exceeds the user-specified timeout. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
