-
Notifications
You must be signed in to change notification settings - Fork 57
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
TypeError when parsing slurm_stderr in ex_hpc #47
Comments
Oops. Hmm, wonder if that is something with Python 3 that made it do a more proper distinction between strings and byte streams, or something. Could it be that the stderr in this case contains some extra (non-string) characters like for colors or something? Anyhow, it seems to me that you fix should be safe.
Do you have access to the |
So, regarding the bytes/string issue, I think you are right, it's a Python 3 thing. In particular, I found this answer, which says:
I have been looking at what's the best way do convert to string, some people suggest Regarding the |
Cool, TIA!
Ah, yes, I think I see why: The shell expansion of the variable, will happen when the command is first issued, which is on the login node. Then SLURM will take care of executing the command on the login node (since it is prepended by Not sure what is the best way to fix that ... perhaps by putting your host-lookup in a separate shell script. Then that should only be executed once on the compute node. |
Thanks for the tip on the shell expansion. I was able to fix it as you suggested by putting the command in a bash script. I will write up a draft for a wiki page with the example. |
PR submitted! |
Hi,
Apologies for opening so many issues today. I have adapted the wiki example for SLURM, and have changed it such that it replaces
foo
with the hostname where the job is running. Code is available at this gist. I was testing it on a SLURM cluster, and gotI made a quick fix by changing line 147 of
slurm.py
fromself.log_slurm_info(stderr)
toself.log_slurm_info(str(stderr))
.. It works, but I have no idea whether it will break in other circumstances. That said, my job still runs on the login node and does not reach the queue apparently, if you know why that may be the case, let me know.Cheers,
Pietro
The text was updated successfully, but these errors were encountered: