Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include transfer file name in etd message log level < 4? #15

Open
varenius opened this issue Jun 16, 2021 · 3 comments
Open

Include transfer file name in etd message log level < 4? #15

varenius opened this issue Jun 16, 2021 · 3 comments

Comments

@varenius
Copy link

etd logs to syslog. With default message level, no information is written about ongoing transfers.
It is very useful to be able to see what file is being transferred. This serves to see if the correct files are being transferred and what the progress is of an ongoing transfer of many files. I thought that "filename" would be the first thing logged if giving etd the "-m 1" flag, but that's not the case. It seems one has to go all the way to "-m 4" to get the filename in syslog. Then, I also get a LOT more information which is not of interest. I'd suggest including the filename, e.g. the line
Jun 16 09:47:41 skirner etd[10755]: 2021-06-16 07:47:41.01: ETDServerWrapper::handle()/got line: 'read-file 0 /mnt/vbsmnt/b21096_ow_096-1929_3'
in the first log level (1) and all the ones above it. Operationally, this is (I think) the most fundamental bit of information, after the fact that etd has started.

If possible, it would also be very good to get the final transfer speed in the logfile after a transfer has finished. It is very useful to be able to monitor files and speeds from the server side too.

@haavee
Copy link
Member

haavee commented Jun 16, 2021

Fair points! I think these can be addressed moderately easy indeed.
The one snag I can immediately think of is that some of the code (specifically the bit that does the actual transfer and does the byte+time keeping) is unaware of whether it is running in the daemon or the client. The unexpected side-effect could be that your client terminal output would be spammed with the same messages as you'd rather see go to the daemon log.

This was by design to have identical code for client->server and server->server transfers i.e. minimize implementation complexity and maintaining different code paths for what should (could) be literally the same process - i.e. moving X bytes from A to B ... ;-)

@varenius
Copy link
Author

Good ideas. Not sure what's best. As it is now, it seems the software is good at telling the user how it does things, but not what it does :). Being a silly end-user, I'm more interested in the what than the how ;).

@haavee
Copy link
Member

haavee commented Jul 2, 2021

Please try the https://github.com/jive-vlbi/etransfer/tree/issue-15 branch, should be more informative at level 1, and found + fixed an issue in the client as well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants