add streamlog #64
add streamlog #64
Conversation
|
A tour de force. The handling of non-display servers (for those who haven't switched) is very considerate. I learned a lot just reading the code for that. Thanks and thanks. I made a couple comments on the code, but also:
|
streamlog/streamlog
Outdated
| if ! fsserver status > /dev/null; then echo fsserver not running; exit 1 ; fi | ||
| if ! fsserver fs status > /dev/null; then echo fs not running; exit 1; fi | ||
| FS_SERVER_URL_BASE=$(awk '/FS_SERVER_URL_BASE/ {gsub(/"/, "", $3); print $3}' /usr2/fs/include/params.h) | ||
| exec ssub "$FS_SERVER_URL_BASE/log" |
There was a problem hiding this comment.
For pre-beta1, replace this line with:
exec ssub -s -w ipc:///var/run/fsserver/windows/fs/{pub,rep}
There was a problem hiding this comment.
As above. Any compelling reason to backport it?
There was a problem hiding this comment.
I see no reason to backport it, but there is a station with a need. They can use a local copy with the change until they can update. I thought it might be good to record the change needed. Maybe the update notice would be a better place.
|
I withdraw my point 2. It is better to wait indefinitely in case it is being run from |
Yeah not much you can do about that. It should print the header of a new file. If not, that age test might need some tweaking. I actually wrote the original version of this script at AuScope, and that drawback was one of the motivators for the server.
Mmm good point. I think the behaviour of the non-server branch is more useful for things like log monitors. The server branch can use ssub's
Yup, if you wanted to do this, you could split out that first half and exit.
Right, exactly.
Simply forgot 😄 |
|
Re point 2: both branches now have the same behaviour when the FS is restarted (ie waiting). Still though, for the server branch, if the FS or fsserver aren't running when streamlog is called, it will exit. This is racy. Fixing this might be just removing these lines: but I need to check how ssub responds. |
|
I don't know. It seems like the first is need to decide which branch to use. Maybe the second isn't if it is suppose to wait for the FS. Using the test (to I guess waiting for the FS to re-/start is more consistent with the client's behavior. I guess that is another reason to not do it. |
|
Curious thing, with something like this in
the two processes in the pipeline are left running after a |
|
Is that with the “-w” flag in ssub? Because ssub should exit without that,
but otherwise it should hang around.
…On Thu, 3 Sep 2020 at 19:25, Ed Himwich ***@***.***> wrote:
Curious thing, with something like this in stpgm.ctl:
strml n streamlog | stream_check &
the two processes in the pipeline are left running after a terminate if
the display server is *not* being used (bad outcome of course, you get
another instance when the FS is restarted, and on and on). However, they
are killed off on terminate when the display server is being used (good).
Maybe this difference is related to the exec used in the display server
and/or something about process group handling. It may require a black belt
in the latter to solve. Maybe there is a simple solution. If not, running
without the display server is deprecated anyway; maybe just say streamlog
can't be used in stpgm.ctl without the display server.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#64 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAZ6PRBA3XOJ4I2AI4KSSHLSD5OINANCNFSM4QLXMVCA>
.
|
|
This is complicated to explain. Run from For tests with both the "pre-beta1" and "up to date" versions with |
|
It seems like if there were a "wrapper" program run from |
|
Any feelings about how this should proceed? I think the two Is having a wrapper a solution to having it in |
|
streamlog is very useful and would be good to get on the main branch. As a result, I am trying to come up to speed on this again. After two years it is not easy. It does give some perspective though. My current thinking is that we could make streamlog only for the display server. The non-display server part can be broken out in a separate utility, maybe follow_log, in misc/ that people can use if they don't want to use the display server. It should have a warning that it should not be used in stpgm.ctl. This would also get us out of the rabbit hole of trying to make the behaviours the same. Other points: For the display server use, we could make Maybe all command line options should just be copied to ssub. OTOH, they could be parsed explicitly in case there are more arguments for streamlog someday. Not to be lazy, but maybe wait to cross that bridge when we come to it. There should be a '-h' option though.
I am not sure now exactly what raciness you were concerned with here. It can't be that starting streamlog from stpgm.ctl might fail. You can get into trouble if the server terminates after these checks and before ssub is run. You would be stuck with ssub running anyway. I suppose those might just be the breaks. Using If this makes sense, it could start to be tested with the changes of #176. |
It turns out that this is related to streamlog looping forever waiting for the FS to restart. Why the Anyway, I changed streamlog to accept two arguments:
This way the user can decide what functionality they want. The I moved the Lastly, I reduced the size for showing the whole log with tail to be just a bit larger than a new log's opening size. As a result, there may be less irrelevant "scroll-back" for small logs. It may make sense to have this depend on Some log lines may not get streamed when the FS is started ( I will let this soak a bit and come back to it in a few days for more testing and cleanup. Any comments would be appreciated. |
|
This is a proposed final version. Some minor issues were fixed. The most significant change is that It looks like the reason a pipeline in stpgm.ctl isn't killed off when the FS is terminated is that the individual steps in the pipeline are run spawned as separate processes and the spawning process is not their session leader. This is easily finessed by just not using |
wehimwich
force-pushed
the
streamlog
branch
2 times, most recently
from
c4a3b25
to
f13fa08
Compare
Added options including help, wait, and scroll-back. Don't set TRAP for EXIT until expecting a 'tail' process to exist; this avoids spurious errors if control-C is used during a wait. The use of tail was changed to provide a limited scroll-back function that may help pick up some missing lines when there is a log change if the FS isn't generating a lot of output at that point.
This is only available if the display server is enabled.
for consistency with other scripts.
|
Added |
This adds a utility to stream the log (and follow it as the output changes). It uses the FS server log stream if the server is enabled, otherwise falls back to
tail -fing the active log while pollinglognm.It has the advantage over a simple
tail -f /usr2/log/$(lognm).logthat it will continue to work after the FS switches to a different log. While with the FS server based method streamlog shouldn't drop messages, this isn't guaranteed for the fallback method when switching to a log that has already been written to (eg "station.log").The server method could work remotely as
ssubshould be compilable on any modern UNIX based OS, even without the FS, and should be fairly reliable on poor networks. Otherwise,ssh pcfs streamlogshould be fine on a reliable network.