Offline resize requires to run fsck -f first. Because we support only
growing that image, we can simply use online resize instead.
This finally fixesqubesos/qubes-issues#772
Apparently it doesn't help much with DispVM startup time, but causes a
lot of problems when such app do not close in time (either can be killed
forcibly and will complain about it at next run, or will spontaneously
show itself when DispVM is started).
This will probably break some user configuration. Do that only when
installing for the first time (during template build), during upgrade
set only those installed by this package instead of all.
systemctl is-enabled always reports "disabled" for them (actually not a
real "disabled", but and error, but exit code is the same). So simply
always disable the unit, it is no-op for already disabled ones.
BTW systemctl preset also do not work for them.
Simply forget about that connection, instead of waiting for further
messages. If that connection is no longer available, select would return
EBADF, which would cause qrexec-agent termination.
/usr/local resides in private.img, so it is possible to define per-appvm RPC
Also, with the upcoming 3.0 release support for old (R1) paths is
removed.
In case of remote process exit even when some messages are still
waiting, vchan connection can be already closed. If we try to send some
data in this case (for example stdout of local process), there will be
an error, which will terminate qrexec-client-vm/qrexec-agent child. So
first check vchan data (where could be MSG_EXIT_CODE queued) , then
local process.
There is still some race condition in this code - remote process could
exit just after we check vchan, but before we send some data. But this
is much less probable and in the worst case we only loose remote process
exit code.
Child process can request to use single socket for both stdin and
stdout by sending SIGUSR1 signal. If it does so twice or more, previous
code broke the connection by closing the socket.
This doesn't cover all the cases, because local process could want to
receive that value (currently it cant), but I can't think of any simple,
*compatible* way to pass it there.
This way qrexec-client-vm will have much more information, at least:
- will know whether the service call was accepted or refused
- potentially will know remote process exit code
This commit implements the first point - the local process will not be
started if service call was refused.
