allow for qlever start to run in the foreground in native mode

[sennierer]

Since ad-freiburg/qlever#1439 has been merged its possible to run qlever-control directly within the container. Thats great, but currently these lines

qlever-control/src/qlever/commands/start.py

Lines 112 to 113 in 547add9

	else:
	start_cmd = f"nohup {start_cmd} &"

put the server process in the background. We are using qlever in a kubernetes cluster and would like to just run qlever index && qlever start. Given that kubernetes marks the container as completed when the server process is moved to the background we need to run a loop to keep the container up.
Could we maybe add another system option called native_foreground (or similar) and change 101 ff in start.py to something along the lines of:

        if args.system in Containerize.supported_systems():
            if not args.server_container:
                args.server_container = f"qlever.server.{args.name}"
            start_cmd = Containerize().containerize_command(
                    start_cmd,
                    args.system, "run -d --restart=unless-stopped",
                    args.image,
                    args.server_container,
                    volumes=[("$(pwd)", "/index")],
                    ports=[(args.port, args.port)],
                    working_directory="/index")
        elif args.system == "native":
            start_cmd = f"nohup {start_cmd} &"

Didnt test this but I suspect the start_cmd without nohup would keep the server process in the foreground and prevent kubernetes from marking it as completed.

[Qup42]

You could use qlever index && qlever start && qlever log as a workaround. This has the added benefit that you get the logs on stdout. If you don't need that you could also use the usual tricks (like tail -f /dev/null, sleep infinity or cat) to keep a container running.

Does this solve your problem?

[sennierer]

yes, thats what we are doing for now. However, I think it would be cleaner to have the server process just run in the foreground of the container. I'll give qlever log a try. Given thats it not a super important issue and its not preventing us from using the service you can close the issue. However, I would suggest to either remove the nohup from the native start command (its easier to just wrap qlever start in nohup than the other way round) or add a foreground option as suggested above.