1 - This example sets the access_log to /dev/null, and the error_log is
redirected to stderr which is displayed in the qemu terminal. How can I
have access to the access_log ? (you can also view this question in
stackoverflow
<http://stackoverflow.com/questions/36706926/rump-unikernel-nginx-logs>)
I guess it depends on your use case. For example, you can configure a
block device with a file system, and log to that. Or, you can configure
access_log to appear on the console and read it from there.
The usability interface for logging is really more of a question for the
Orchestrating System (OS) built on top of the Rumprun unikernel.
2 - Many applications generates information that requires persistence.
How
could I enable persistence in a rump unikernel ?
I assume that by persistence you mean persistence of data across
instances. Again, it depends on your use case. For example, you can use
cloud storage, or a "local" file system (where "local" might mean on the
cloud -- the cloud is recursively confusing).
I am afraid that I might be facing this problem, but I am not sure about
The remaining issue is how to get the application to sync its data to a
clean state. Some applications support an "in-band" method for signalling
a sync, e.g. rumprun-nethack will save the game when the user presses "S".
For applications which don't support that, normally a signal is used. With
rump kernels and therefore Rumprun taking heed of the "signals are evil"
tautology, the signal approach won't work out-of-the-box. Some code
remains to be conjured up to address the general case.