DOMjudge-devel March 2018

domjudge-devel@domjudge.org

6 participants
6 discussions

Differences between master and ICPC-live
by Tobias Werth 28 Mar '18

28 Mar '18

Hi, I want to get rid of the ICPC-live branch as soon as possible after the finals. I also think that we should do this first before we do any further symfony migration. This is a list of the differences to get the discussion started (I probably missed some things): 1) entry_point handling Options: a) add a global configuration b) always require an entry_point if the language itself requires an entry_point c) detect entry_point on domserver I would go with b). By default we can use compile scripts that auto-detect and configure languages as such. In a setting primary/shadow setting, we can require entry points as we do now. 2) Minor things: - Pause contest countdown / starttime_enabled - tsv/yaml import scripts - results/tsv export scripts There's no reason to disable these. 3) external IDs / external results - have only one database scheme, i.e. include columns for external_ids and _results - why don't we always use the contest shortname as ID in the API? - can we drop the expected result in favor of external results? (note that we didn't do a comparison on testcase level in the past but might want to do it in the future) - external_ids and _results can be used even in primary mode where we could fetch the results from the secondary 4) display test case results in submission lists Options: a) make it configurable (either per contest or globally) b) always display them (for jury of course) I don't think the test case results clutter the submission page too much, so I would just keep them always on for simpler code. 5) removed time intervals The code in calcContestTime looks fairly simple. The UI only affects the contest page. Did I miss anything? Best, Tobi

4 4

use installed library during the execution of the runguard
by Guillaume MILAN 23 Mar '18

23 Mar '18

Hello, I installed a software library on my debian system with apt-get. But the library doesn't appear in the /usr/lib folder during the runguard execution. As i understood you create temporary symbolic link in the root folder of the chroot execution which is located in the folder c<contest>-s<problem>-j<id>. >From where do you create your symbolic link. Regards Guillaume

2 2

[USER] Non-zero exitcode
by Guillaume MILAN 14 Mar '18

14 Mar '18

Hello, I am currently trying to create my own run and compare script for the judging system and I got the following message as output. Non-zero exitcode runtime: s cpu, s wall memory used: bytes ********** runguard stderr follows ********** The exit code is 0 But my both script execute their self correctly and the run script exit with 0 exit code and the compare script exit with the 42 exit code Had I missed something? Regards Guillaume Milan

2 1

Re: [USER] Parallel authentication
by Jaap Eldering 13 Mar '18

13 Mar '18

Hi Guillaume, Sorry that this message wasn't replied to immediately. Also, the correct email address for the list is domjudge-devel(a)domjudge.org not the -owner variant, I'm CC-ing it to the list now. Note that you have to subscribe to be able to send emails to the list. On 05-03-18 17:56, Guillaume MILAN wrote: > Dear developers, > I am currently trying to develop a parallel way for user to login to my server. Indeed, I installed the domjudge server and I have write some scripts to verify via my ldap server that the user is in my ldap database. > > But I would like to know how can i verify if a user is in the domjudge data base and > - if yes verify his password to log him in and > - if he isn't in the domjudge data base I would like to create a domjudge account for him. (does a sha512 hash will be supproted as user name?) > > > Is there any document that describe your authentication process. We're currently changing to using Symfony in master, and there we didn't setup LDAP authentication yet. However, up to version 5.3 you can configure to authenticate users against an LDAP server. See etc/domserver-config.php, the LDAP authentication method and related settings. The authentication code lives in lib/www/auth.php. We also have an option to allow users to self-register with DOMjudge, see the configuration settings in the admin web interface. I'm not the most familiar with this code, so others might want to step in with more details. Best, Jaap

1 0

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

DOMjudge-devel March 2018