Messages for package

[jankom]

Hi,

Is there a way to recover compile messages after eix-sync command and subsequent emerge -avuND --with-bdeps=y @world command?

My problem is that when I do an eix-sync system update on a remote box (ssh connected virtual server) the connection cuts out after a certain time of user inactivity (probably a good security feature) I lose my terminal to the remote machine. Output (console-terminal) of the emerge -avuND --with-bdeps=y @world command is gone because compiling typically takes long time.

Maybe some unix trick could help, such as redirecting output to a file or "> foo.txt" appended to the emerge command?

I was searching for these messages in /var and other places, but apparently they are not saved.

This is not a problem on my home machine because even after the "emerge..." command completes after a couple of days the terminal is still there, so I can review these messages and act upon them if needed.

jankom

[logrusx]

Use screen, tmux or other similar session manager (or whatever this feature is called)

Best Regards,
Georgi

[sublogic]

Hi,

Is there a way to recover compile messages after eix-sync command and subsequent emerge -avuND --with-bdeps=y @world command?

Look in /var/log/portage/elog/summary.log ?

[flexibeast]

Also, there's the `keepwork` feature (as in, specified via the FEATURES variable) for make.conf.

[flexibeast]

Use screen, tmux or other similar session manager (or whatever this feature is called)

'Terminal multiplexer' is the usual 'generic' phrase i've encountered.

[rab0171610]

My problem is that when I do an eix-sync system update on a remote box (ssh connected virtual server) the connection cuts out after a certain time of user inactivity (probably a good security feature) I lose my terminal to the remote machine. Output (console-terminal) of the emerge -avuND --with-bdeps=y @world command is gone because compiling typically takes long time.
This is not a problem on my home machine because even after the "emerge..." command completes after a couple of days the terminal is still there, so I can review these messages and act upon them if needed.

It is only a good security feature when it matches or meets the user's individual security needs. Security features that exceed this threshold are too restrictive and can be a hindrance more than a help. Fortunately, you can modify the ssh configuration to meet your security requirements. With regards to timeouts, you can look at:

Code: Select all

 ServerAliveCountMax
    Sets the number of server alive messages (see below) which may be sent without ssh(1) receiving any messages back from the server. If this threshold is reached while server alive messages are being sent, ssh will disconnect from the server, terminating the session. It is important to note that the use of server alive messages is very different from TCPKeepAlive (below). The server alive messages are sent through the encrypted channel and therefore will not be spoofable. The TCP keepalive option enabled by TCPKeepAlive is spoofable. The server alive mechanism is valuable when the client or server depend on knowing when a connection has become unresponsive. The default value is 3. If, for example, ServerAliveInterval (see below) is set to 15 and ServerAliveCountMax is left at the default, if the server becomes unresponsive, ssh will disconnect after approximately 45 seconds.

ServerAliveInterval
    Sets a timeout interval in seconds after which if no data has been received from the server, ssh(1) will send a message through the encrypted channel to request a response from the server. The default is 0, indicating that these messages will not be sent to the server.

See also:
https://wiki.gentoo.org/wiki/SSH
and
https://man.archlinux.org/man/ssh_config.5.en
For example, you can edit the global ssh configuration in /etc/ssh/ssh_config (or a subfile /etc/ssh/ssh_config.d/*.conf). You can set one or both of ServerAliveInterval and/or ServerAliveCountMax to higher values and see what works best for your needs.
Extreme examples:

Code: Select all

ServerAliveInterval 999999
ServerAliveCountMax 999999

In my case, I might be updating a laptop in the same house or in the same room even. I might just be too tired to get up and go over to the machine to do the updates. Sometimes it is just easier to do it from the machine I am working on and this also allows me to keep an eye on the progress in the terminal. The security requirements on my own network are not high. For me, in this case, the ssh timeout is pointless, especially considering I might be doing updates or rebuilds that can take several hours.

[Hu]

ServerAlive* is only to detect when the peer becomes unavailable, whether due to crash or suspend. It is not sensitive to idle time, and will not drop a session solely due to inactivity by the user.

[wjb]

You can save the build logs by setting PORT_LOGDIR in /etc/portage/make.conf, /var/log/portage. You can also log the errors/warnings from the builds by setting PORTAGE_ELOG_SYSTEM and friends. Details in the Gentoo Handbook -> Portage -> Files and Directories.

[rab0171610]

ServerAlive* is only to detect when the peer becomes unavailable, whether due to crash or suspend. It is not sensitive to idle time, and will not drop a session solely due to inactivity by the user.

Thank you Hu. I was trying to point out that besides addressing the issue of saving emerge output, there also has to be a way to configure the ssh timeout to better suit the user's needs using ssh_config. I do not think it is desirable to have ssh timeout when doing Gentoo updates remotely. My post was mostly theoretical and I should have been more clear.

I remember reading about it at length at some time in the past. It may have been:
https://www.simplified.guide/ssh/disable-timeout
I don't know if that is entirely accurate, Hu may be able to say for certain.
It explains settings for TCPKeepAlive, ClientAliveInterval , ClientAliveCountMax from the server side or when not possible
ServerAliveInterval from the client side.

[jankom]

In the meantime I think I found a workaround:

There is a summary.log file in /var/log/portage/ that has roughly the same messages as shown in the terminal after emerge... command completes. I discovered that while updating my home desktop machine (3 days compile time) but never lost the terminal.

I can now peruse this file with an editor (read only) and decide what other action needs to be taken.

A corollary question (again, just my curiosity):

Desktop (local) machine
/var/log/portage/ has two directories: elog and log
/var/log/portage/elog/ directory is empty
/var/log/portage/log/ directory has another elog directory which has the summary.log file.
In addition /var/log/portage/log/ directory has zillion log files pertaining to individual package compile logs. In fact presently it has 2G total content

Remote machine
has only /var/log/portage/elog/ directory containing just the summary.log file

Is there an explanation for this? Something in the make.conf file that is different between the two systems? Why there is no individual package log files in the remote machine?

I try to manage these two machines to be similar except for the fact that the home machine is gui capable. I only need terminal programs on the remote machine.

jankom

[Hu]

As regards ssh timeout, my experience has been that I can maintain an ssh connection indefinitely, if the following conditions are met:

• There are no external processes on the server that attempt to kill my shell for exceeding some arbitrary lifetime limit.
• The shell on the server does not use TMOUT to self-terminate after inactivity.
• There is no activity over the connection during the period when one end is suspended or otherwise offline. This requires both that ssh not send alive messages and that nothing running in the terminal try to update the display. For example, a write can cause activity that will kick me off. However, write can be blocked by mesg n.

That last one is interesting in that I put my personal system into suspend when I will be away for an extended period. I keep an ssh session to a server which stays up indefinitely. I configured that server to send ssh alive messages very sparingly (once every few days). I set mesg n on the terminal. Combining all those, I can have the client suspended for hours at a time, and the ssh connection is still present when I resume.

[logrusx]

A corollary question (again, just my curiosity):

Desktop (local) machine
/var/log/portage/ has two directories: elog and log
/var/log/portage/elog/ directory is empty
/var/log/portage/log/ directory has another elog directory which has the summary.log file.
In addition /var/log/portage/log/ directory has zillion log files pertaining to individual package compile logs. In fact presently it has 2G total content

Remote machine
has only /var/log/portage/elog/ directory containing just the summary.log file

Is there an explanation for this? Something in the make.conf file that is different between the two systems? Why there is no individual package log files in the remote machine?

I try to manage these two machines to be similar except for the fact that the home machine is gui capable. I only need terminal programs on the remote machine.

jankom

The most useful posts are at the last page I think:

https://forums.gentoo.org/viewtopic-t-131795.html

There was another thread, but it was unpinned. It was about elogviewer and I believe it contained the configuration that did that as well. However there's nobody to maintain elogviewer and the thread was unpinned.

Also I believe you might have stumbled on this wiki page and you even may have followed it: https://wiki.gentoo.org/wiki/Elogv

Undo the two lines listed there from make.conf and you'll get regular summary.log.

Best Regards,
Georgi

[asturm]

fwiw, elogviewer was recently ported to Qt6 so it is here to stay.

[logrusx]

fwiw, elogviewer was recently ported to Qt6 so it is here to stay.

That's very good news, thanks for sharing!

Best Regards,
Georgi

[jankom]

Looking at the summary.log file it would seem to me that I could recover the lost emerge... output messages by searching for WARN: postinst sections there.

That works for me.

jankom