echo does not work in %startscript about singularity HOT 5 CLOSED

This isn't a bug. Because they run in the background, the standard output and standard error of instances are redirected to log files. You need to look in these files, the output will not be on the screen.

This is fully documented in the user guide, instance section:

https://docs.sylabs.io/guides/4.0/user-guide/running_services.html#instance-logs

from singularity.

This isn't a bug. Because they run in the background, the standard output and standard error of instances are redirected to log files. You need to look in these files, the output will not be on the screen.

This is fully documented in the user guide, instance section:

https://docs.sylabs.io/guides/4.0/user-guide/running_services.html#instance-logs

Running in the background does not mean the command cannot output to terminal. An example is
echo "background can output" &
Here, echo is running in background, but it can still output to terminal.

Of course, if it is redirected, then there is no output. But I think this designed behavior is counter-intuitive because most people expect to see the output in terminal.

from singularity.

I'm afraid that this is by design, and isn't a behaviour that will be changed.

The instance functionality is designed to run long-running services, where output is generally expected to be to log files. If you run e.g. a web server in an instance, it is unlikely that you would want all of the log output to appear on your terminal. It would clash with whatever you contined to do in that terminal.

When you run echo "hello" & in the background from a shell it is attached to a terminal. If the terminal is closed then the command would stop. We don't want a container to exit if you close the terminal where you started it - therefore the way it is run in the background is different to using & in a shell.

You can think of starting an instance to be more like running a command with nohup, which will also redirect the output to a file, and avoid the command being stopped if the terminal is closed.

As I mentioned, the behaviour is clearly documented in the instance user guide - https://docs.sylabs.io/guides/4.0/user-guide/running_services.html#instance-logs

from singularity.

I don't know the details of the design of Singularity, but in my memory, if a process forks a new process, this sub-process does not have to exit together with the parent-process (more often it is re-parented by the system). Also, my memory is that sub-process can output to the parent-process's terminal because the file descriptor is inherited. So if the terminal is closed, the only consequence is that the user cannot see any output from the sub-process (the commands started in %startscript section). Anyway, I don't know the details of the design of Singularity, so there may be some complexity I didn't understand. I will take a look at overlay and other suggestions you gave. Thanks for your replies.

from singularity.

I don't know the details of the design of Singularity, but in my memory, if a process forks a new process, this sub-process does not have to exit together with the parent-process (more often it is re-parented by the system). Also, my memory is that sub-process can output to the parent-process's terminal because the file descriptor is inherited. So if the terminal is closed, the only consequence is that the user cannot see any output from the sub-process (the commands started in %startscript section). Anyway, I don't know the details of the design of Singularity, so there may be some complexity I didn't understand. I will take a look at overlay and other suggestions you gave. Thanks for your replies.

Did you mean to post this reply on #2506?

FWIW - the issue isn't really handling the exit of a process writing to the terminal. The issue is wiring up the that process to the stdin / stdout of the container. This involves quite a lot of work, as with containers we cross Linux namespace boundaries, we don't just spawn subprocesses but sometimes execve replacing the parent, and consequently may need to do things like pass file descriptors through sockets. or write/read to sockets directly in order to obtain stdin / stderr where it might be needed outside of the container process for display to a terminal. Ultimately it's more complex, and there are rather more Linux specifics involved than are discussed in more general guides to UNIX programming.

If you are ever interested in reading a bit more about how Singularity works, this audit has some diagrams / information that give an overview of how things flow: https://www.ideals.illinois.edu/items/111708

E.g.

Cheers.

from singularity.