[DragonFlyBSD - Bug #3331] dsynth timeout and limits

[bugtracker-admin at leaf.dragonflybsd.org]

Задача #3331 була оновлена daftaupe.


Hi,

after having tried to find some infos, I think there are several things to take into account in your case.

Different timeouts are defined in dsynth.h, being WDOG1 -> WDOG9, if you notice a timeout of precisely 15 minutes, first option is that it's due to the use of WDOG3 in one of the call to dophase. That's the case in phases extract_depends, extract, or configure.

Also the timeout can be scaled up if the average load of the last 15 minutes divided by your number of cores is greater to your number of cores, which could be sumed up as, if I'm not mistaken, if the load of the last 15 mins is superior to your number of cores being squared. In that case the new timeout is defined in the first else case in the following piece of code.
<pre><code class="c">
                        /*
                         * Watchdog scaling
                         */
                        getloadavg(dload, 3);
                        adjloadavg(dload);
                        dv = dload[2] / NumCores;
                        if (dv < (double)NumCores) {
                                wdog_scaled = wdog;
                        } else {
                                if (dv > 4.0 * NumCores)
                                        dv = 4.0 * NumCores;
                                wdog_scaled = wdog * dv / NumCores;
                        }

                        /*
                         * Watchdog
                         */
                        if (next_time - wdog_time >= wdog_scaled * 60) {
                                snprintf(buf, sizeof(buf),
                                         "\n--------\n"
                                         "WATCHDOG TIMEOUT FOR %s in %s "
                                         "after %d minutes\n"
                                         "Killing pid %d\n"
                                         "--------\n",
                                         pkg->portdir, phase, wdog_scaled, pid);
                                if (fdlog >= 0)
                                        write(fdlog, buf, strlen(buf));
                                dlog(DLOG_ALL,
                                     "[%03d] %s WATCHDOG TIMEOUT in %s "
                                     "after %d minutes (%d min scaled)\n",
                                     work->index, pkg->portdir, phase,
                                     wdog, wdog_scaled);
                                kill(pid, SIGKILL);
                                ++work->accum_error;
                                break;
                        }
</code></pre>

But I think that if you see some exact number of minutes in the log, it means it's using the default defined value of WDOG3 if it's during extract phase.

Maybe you could try to change the value of WDOG3 to something bigger, see if that allows you to go past this step for chromium ? You would need to recompile dsynth for that.

----------------------------------------
Bug #3331: dsynth timeout and limits
http://bugs.dragonflybsd.org/issues/3331#change-14433

* Автор: arcade at b1t.name
* Статус: In Progress
* Пріоритет: Normal
* Версія: 6.4
* Початок: 2022-09-26
----------------------------------------
Hello.

Watching dsynth I often see that it wants to limit number of running jobs, but actually it just prevents new jobs starting. Also under huge load like building other packages sitting in swap jobs can timeout.

For example build reaches chromium while building something huge like firefox with almost no free mem. This means extracting chromium we would need to write a lot of data to swap while reading it from disk and other build also will be swapping a lot. For me it can take more then 15 minutes sometimes.

It would be really nice that this timeout could be configurable.

Also on the limits: it's really easy to suspend any job by `kill -17 -JOB_PID`, this will make all process group STOP for now. Later it can be resumed with -19.

Big thanks in advance, hope this can be interesting as an improvement.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account