[JENKINS-30101] Keep user specific reason for offline slave when slave getting disconnected

[jenkins-infra-bot]

Jenkins 1.598

1. When taking slave offline by user - you can specify a reason.
If the slave is getting disconnected (i.e. after a reboot), the reason is changed to a java exception, and you can't see the original reason.

2. When a slave is in a "connecting" state (slave agent being lunched) and is in offline state - the reason doesn't appear on the computer page (/computer/host...).

---

Originally reported by galunto, imported from: Keep user specific reason for offline slave when slave getting disconnected

• assignee: vlatombe
• status: Closed
• priority: Minor
• component(s): core
• label(s): 2.492.1-fixed
• resolution: Fixed
• resolved: 2024-10-16T13:24:43+00:00
• votes: 0
• watchers: 3
• imported: 2025-11-24

Raw content of original issue

Jenkins 1.598

1. When taking slave offline by user - you can specify a reason.
If the slave is getting disconnected (i.e. after a reboot), the reason is changed to a java exception, and you can't see the original reason.

2. When a slave is in a "connecting" state (slave agent being lunched) and is in offline state - the reason doesn't appear on the computer page (/computer/host...).

[jenkins-infra-bot]

• Remote links associated with this issue:

  • PR-6152
  • PR #​9855

[jenkins-infra-bot]

integer:

• Original comment link
• Raw content of original comment:

  1. Jenkins restart is one thing, after jenkins start it calls computers.updates (afair). So something can be related in this part of code.
  
  2. probably can be related to asynchronous actions between submitted runnable in threadPoolForRemoting (afair in this way it launches slaves) and offline marking/interruption.
  

1. Jenkins restart is one thing, after jenkins start it calls computers.updates (afair). So something can be related in this part of code.

2. probably can be related to asynchronous actions between submitted runnable in threadPoolForRemoting (afair in this way it launches slaves) and offline marking/interruption.

[jenkins-infra-bot]

galunto:

• Original comment link
• Raw content of original comment:

  1. when I said reboot - I meant a reboot of the slave (Channel Termination)
  
  2. I guess you right.. Anyway, this is much less important 
  

1. when I said reboot - I meant a reboot of the slave (Channel Termination)

2. I guess you right.. Anyway, this is much less important

[jenkins-infra-bot]

galunto:

• Original comment link
• Raw content of original comment:

  hudson/slaves/SlaveComputer.java 
  1. In the function setChannel there is the line(531):
  offlineCause = null;
  which remove the offline cause after the slave reconnect.
  I don't think this is the right behaviour we expect - The offline state should remain in case it made by User / CLI.
  
  2. line 473
  We might override a user offline cause with a ChannelTermination cause. I think the right way is, again, check if there is a user / CLI cause and if so - don't change it. although I'm not sure if I don't miss anything here... (what is the expected behaviour in case that the node is offline and it disconnect from the slave...)
  

hudson/slaves/SlaveComputer.java
1. In the function setChannel there is the line(531):
offlineCause = null;
which remove the offline cause after the slave reconnect.
I don't think this is the right behaviour we expect - The offline state should remain in case it made by User / CLI.

2. line 473
We might override a user offline cause with a ChannelTermination cause. I think the right way is, again, check if there is a user / CLI cause and if so - don't change it. although I'm not sure if I don't miss anything here... (what is the expected behaviour in case that the node is offline and it disconnect from the slave...)

[jenkins-infra-bot]

newtopian:

• Original comment link
• Raw content of original comment:

  I would make this as a bug rather than an improvement.  This makes Offline reasons provided by the user completely useless as a communication tool within the team regarding why this specific agent is offline.
  
  The Offline Reason is Effectively broken in the current behavior
  

I would make this as a bug rather than an improvement.  This makes Offline reasons provided by the user completely useless as a communication tool within the team regarding why this specific agent is offline.

The Offline Reason is Effectively broken in the current behavior