Actually rm -r does not give ANY warning, so in plain Linux "rm -r /" run
as root would destroy your system without notice. Your particular Linux
distro may have implemented safeguards with a shell alias such as `alias
rm='rm -i'` and that's a common thing, but not guaranteed to be there
On Thu, J
Given that the usual way to kill a job that's running is to use scancel, I
would tend to agree that killing by shortening the walltime to below the
already used time is likely to be an error, and deserves a warning.
My opinion is no, at least not forced.
On Thu, Jul 6, 2023 at 1:40 PM Amjad Syed wrote:
> Agreed the point of greater responsibility but even rm -r ( without
> f) gives a warning. In this case should slurm have that option (
> forced) especially if it can immediately kill a running
Agreed the point of greater responsibility but even rm -r ( without
f) gives a warning. In this case should slurm have that option (
forced) especially if it can immediately kill a running job?
On Thu, 6 Jul 2023, 18:16 Jason Simms, wrote:
> An unfortunate example of the “with
An unfortunate example of the “with great power comes great responsibility”
maxim. Linux will gleefully let you rm -fr your entire system, drop
production databases, etc., provided you have the right privileges. Ask me
how I know…
Still, I get the point. Would it be possible to somehow ask for
con
Yes, the initial End Time was 7-00:00:00 but it allowed the typo (16:00:00)
which caused the jobs to be killed without warning
Amjad
On Thu, Jul 6, 2023 at 5:27 PM Bernstein, Noam CIV USN NRL (6393)
Washington DC (USA) wrote:
> Is the issue that the error in the time made it shorter than the ti
Is the issue that the error in the time made it shorter than the time the job
had already run, so it killed it immediately?
On Jul 6, 2023, at 12:04 PM, Jason Simms
mailto:jsim...@swarthmore.edu>> wrote:
No, not a bug, I would say. When the time limit is reached, that's it, job
dies. I wouldn'
No, not a bug, I would say. When the time limit is reached, that's it, job
dies. I wouldn't be aware of a way to manage that. Once the time limit is
reached, it wouldn't be a hard limit if you then had to notify the user and
then... what? How long would you give them to extend the time? Wouldn't be
Hello
We were trying to increase the time limit of a slurm running job
scontrol update job= TimeLimit=16-00:00:00
But we accidentally got it to 16 hours
scontrol update job= TimeLimit=16:00:00
This actually timeout and killed the running job and did not give any
notification
Is this a bug, sh