DOMjudge-devel February 2018

domjudge-devel@domjudge.org

6 participants
5 discussions

Live ISO Issue
by Matthew Fahrenbacher 03 Mar '18

03 Mar '18

Hi all - I'm having trouble writing the most recent live ISO file to a USB drive. I've downloaded the latest img from here: https://www.domjudge.org/live/ And used the bzcat command to write data to my usb drive (as root) bzcat domjudge-live_2018-01-09.img.bz2 > /dev/sdb When I boot from the usb stick, I get the menu to pick what I want to boot the computer as (webserver and judgehost, just judgehost, etc), but whenever I pick an option, I drop into intramfs with an errir bout 1 table load failing and 7 loading successfully. Does it matter what format the USB is in before I run the bzcat operation? I didn't think so... [image: Inline image 1] Thanks (and I apologize if this has been answered before)! Matt Fahrenbacher

2 6

[Dj] CPU time vs. Wall time
by PEDRO PABLO GOMEZ MARTIN 02 Mar '18

02 Mar '18

Hello, I've been using DOMjudge since the old 3.x days, and in the last few years I've been applying a couple of changes in my new installations to overcome some problems that, IMHO, have arisen with the new versions. I want to share them in case they are useful for others, they can be considered to by applied to the mainstream version, or to get feedback if I've been doing something wrong. The first one is regarding CPU vs. wall limit times. When runguard is invoked from testcase_run.sh, the script provides it with the parameters --cputime and --walltime. Years ago the walltime was set with 2*${TIMELIMIT}. But at some point in the past, the format of $(TIMELIMIT) was changed to "<soft>:<hard>" and that expression stop working. The script was updated and now the --walltime is exactly the same as --cputime. I experienced difficulties because of that some time ago, because runguard reported Time Limit due walltime exceeded even when the CPU limit was far to be reached. This occurred when the server was suffering a high load, or the first time a big testcase had to be recover from the database. My solution has been to change that script (testcase_run.sh) so the walltime is scaled up. The official script is: runcheck ./run testdata.in program.out \ $GAINROOT "$RUNGUARD" ${DEBUG:+-v} $CPUSET_OPT \ ${USE_CHROOT:+-r "$PWD/.."} \ --nproc=$PROCLIMIT \ --no-core --streamsize=$FILELIMIT \ --user="$RUNUSER" --group="$RUNGROUP" \ *--walltime=$TIMELIMIT --cputime=$TIMELIMIT \* --memsize=$MEMLIMIT --filesize=$FILELIMIT \ --stderr=program.err --outmeta=program.meta -- \ "$PREFIX/$PROGRAM" 2>runguard.err and my change modifies the --walltime line: ... --walltime=*$((4*${TIMELIMIT%:*}))* --cputime=$TIMELIMIT \ ... Note that I'm using a factor of 4 instead of 2 used long ago by DOMjudge. This change works for versions up to 5.1.x. Since DOMjudge 5.2 timelimits can be float values, and my expression is not working anymore. Now bc is needed in order to be able to use float arithmetic: ... --walltime=*$(echo "scale=2;4*${TIMELIMIT%:*}" | bc)* --cputime=$TIMELIMIT \ ... This last patch is due to my college Joan Rodríguez, and adds a new package dependence (in judgehosts) with the bc program. The second change that I've been applying to DOMjudge is in runguard itself, and it is also related with CPU time, although now I'm unsure about the reasons causing my problems. Sometimes, when evaluating java submissions, instead of Time Limit verdict we got Run Error. We solved this issue increasing the real cputime hard limit in runguard. The official runguard adds one second to the CPU time limit, and for some reasons that seems to be insufficient in some cases so we change it to add 2 seconds. In the runguard.c source code: if ( use_cputime ) { /* The CPU-time resource limit can only be specified in seconds, so round up: we can measure actual CPU time used more accurately. Also set the real hard limit one second higher: at the soft limit the kernel will send SIGXCPU at the hard limit a SIGKILL. The SIGXCPU can be caught, but is not by default and gives us a reliable way to detect if the CPU-time limit was reached. */ rlim_t cputime_limit = (rlim_t)ceil(cputime[1]); verbose("setting hard CPU-time limit to %d(+*2*) seconds",(int)cputime_limit); lim.rlim_cur = cputime_limit; ^ lim.rlim_max = cputime_limit+*2*; | setlim(CPU); ^ | } +---------- CHANGED This change avoids those false RUN ERROR verdicts we sporadically suffered. Unfortunally I cannot provide a way to replicate the error because it is quite erratic. As judgehosts we use virtual machines, in case that is important. Thank you for your great DOMjudge. Best regards, Pedro Pablo

2 1

hackathon doodle poll
by Jaap Eldering 24 Feb '18

24 Feb '18

Hi all, We're planning to again organize one or two hackathons in the upcoming two months to advance the API and other tasks, especially focussing on the upcoming ICPC World Finals. If you're interested in joining (non-core/new developers also very welcome!) please fill in the poll: https://doodle.com/poll/vxvs9ri9siq7esgw We're planning to do a full day, roughly between 10 - 20h Europe time, but everyone is welcome to join in when they have time. Best, Jaap

1 5

New team and public UI
by Thijs Kinkhorst 15 Feb '18

15 Feb '18

Hi all, I've just committed to master my attempt at renewing the Team and Public UI's. In my opinion the DOMjudge interface looks a bit dated and could use a fresh coat of paint. Let me know what you think. Note that you need to run composer (see https://www.domjudge.org/docs/admin-manual-10.html#ss10.1) when updating from git sources. It's definitely not "done" in the sense that it could likely be made even better, but I think it's an improvement over what we had. Because of all the developments going on I purposefully kept to relatively minimal changes to get it done (i.e.: no rewriting to templating systems yet, nearly all logic unchanged, scoreboard layout untouched). There's room for more cleanup and refactorng, especailly if we want to change the Jury interface aswell. And if we want to move to proper templating via Twig for the entire interface. That is appropriate for after 6.0 I think. Cheers, Thijs

2 4

I keep getting compiler error
by Mehmet Oguz Yardımcı 03 Feb '18

03 Feb '18

I was trying to setup a domjudge on Digital Ocean Ubuntu Machine. I followed the guide till end. System is running smoothly except that when I try to submit an answer I keep getting this error. Would you please help, I can't fix it for 2 days. Compiling failed with exitcode 255, compiler output: /home/magnus/domjudge/judgehost/bin/runguard: creating cgroup: Failed to remove a non-empty group(50029) Try `/home/magnus/domjudge/judgehost/bin/runguard --help' for more information. Error: failed to set /sys/fs/cgroup/memory/domjudge/dj_cgroup_3376_1517615852/memory.memsw.limit_in_bytes: Cgroup, requested group parameter does not exist

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

DOMjudge-devel February 2018