Nixus stores meaningful logs in the remotes

[lovesegfault]

When a nixus deployment fails inspecting the local log in /var/lib/system-switcher is almost useless as all of the meaningful, informative, logs end up in the remote's /var/lib/system-switcher.

It'd be nice if nixus copied over the failure logs.

[infinisil]

Just pushed c62336b for a temporary fix for less confusion

[bqv]

Implemented this while doing my execline fiddling. Works as follows:

Create a fifo as current/fifo to act as the pipe

Open FD3 to write to the fifo

Dup FD1 (local logs) to FD3 so activation output is copied to the fifo

Set a background process to cat the fifo over ssh into STDOUT inherited from the main progress (ended by EOF from the remote)

To save littering and help ensure EOF is sent when the process ends (no other open writers), delete the fifo when done

[lheckemann]

Dup FD1 (local logs) to FD3 so activation output is copied to the fifo

AFAIU all the output will be sent to the FIFO only with this approach (you're duplicating FD3 to FD1, not duplicating the output to both FDs). I think tee should be used instead, in bash I'd do this using exec > >(tee /path/to/fifo). If the current way is working for you I have no idea why :D

[bqv]

@lheckemann not all the echoes in the switch script go to FD1, some of them are echoed to FD2. Also i am duplicating FD3 to FD1, that's the behaviour of n>&m as I understand it (and experimentally verified) but it is bash, so I wouldn't be surprised if this doesn't work on full moons.

I very very intentionally avoided using tee, because this really doesn't need yet another random process hanging around with the potential to become an orphan, just to open a named pipe

[lheckemann]

Right, I think I may have misunderstood "Dup FD1 (local logs) to FD3 so activation output is copied to the fifo" then — I thought you wanted all output to be sent both to the original stdout and to the FIFO. But if you only want it in the FIFO all is well :)

[bqv]

Ah, no, that's not really necessary. There's already the initial tee copying the output to the log, and the original stdout should be a nohup'd black hole at this point anyway. I'll probably make that more obvious when I turn the bash in my version's switch script into execline script too