linuxserver / docker-webtop

Ubuntu, Alpine, Arch, and Fedora based Webtop images, Linux in a web browser supporting popular desktop environments.
GNU General Public License v3.0
1.97k stars 205 forks source link

[BUG] In Kasm Workspaces I'm getting a kasm_pre_shutdown_root.py and kasm_pre_shutdown_user.py error. #240

Open silmarine opened 6 months ago

silmarine commented 6 months ago

Is there an existing issue for this?

Current Behavior

Not sure if this is the right place for this. I'm having a problem not with webtop itself but how it works with Kasm Workspaces. I added the linuxserver registry to my Kasm Workspaces server and use a few of the workspaces provided by linuxserver. All of them, at least all of the ones i use, throw up 2 errors in kasm when I delete the workspace session or when it self deletes from time out. Following is the error

host: proxy
ingest_date: 202404291457
application: kasm_agent
levelname: ERROR
process: __main__.handler
message
kasm_pre_shutdown_root.sh exceptioned for kasm ID: 712c8be0-db82-46af-971f-eba640ccf95b with exit code: 1 and output: b''

host: proxy
ingest_date: 202404291457
application: kasm_agent
levelname: ERROR
process: __main__.handler
message
kasm_pre_shutdown_user.sh for kasm ID: 712c8be0-db82-46af-971f-eba640ccf95b exceptioned with exit code: 1 and output: b''

I don't get this error with any kasm provided workspaces. It doesn't seem to affect the usage of the workspace either. I just consistently get this error in my logs.

Expected Behavior

No errors on workspace session deletion.

Steps To Reproduce

  1. start a linuxserver workspace, for example the arch xfce workspace or remmina.
  2. delete the session in kasm or let the session timeout and auto-delete.

Environment

- OS:debian 12, kasm 1.15.0
- How docker service was installed:I run the kasm server install script on the OS, it's the only thing running on that machine. Only thing I did after that was add linuxserver registry. Everything else is "stock" kasm.

CPU architecture

x86-64

Docker creation

Whatever Kasm Workspaces does to start a container.

Container logs

host: proxy
ingest_date: 202404291457
application: kasm_agent
levelname: ERROR
process: __main__.handler
message
kasm_pre_shutdown_root.sh exceptioned for kasm ID: 712c8be0-db82-46af-971f-eba640ccf95b with exit code: 1 and output: b''

host: proxy
ingest_date: 202404291457
application: kasm_agent
levelname: ERROR
process: __main__.handler
message
kasm_pre_shutdown_user.sh for kasm ID: 712c8be0-db82-46af-971f-eba640ccf95b exceptioned with exit code: 1 and output: b''
github-actions[bot] commented 6 months ago

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

LinuxServer-CI commented 5 months ago

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

silmarine commented 5 months ago

This is still an issue for me. I have been keeping both Kasm Workspaces and the Arch workspace updated but the errors persist. I would love to provide more information but I don't know what else would be useful.

LinuxServer-CI commented 4 months ago

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

S0ulDrag0n commented 4 months ago

I am getting this issue as well. Can't start any workspaces.

Edit: Seems to only occur with Linuxserver images.

djarbz commented 3 months ago

Looks like the ip command may need to be installed in the container.

/kasminit: line 79: ip: command not found

djarbz commented 3 months ago

Looks like the last image I found to work for me was fedora-kde-version-90fc9ea6

djarbz commented 3 months ago

I ran a diff on the /kasminit file on the latest working image and the next image which doesn't work for me. This section was added, so I think the base image just needs to get the ip command installed.

## Network egress wait ##

while :; do

  interfaces=$(ip link show type veth | awk -F: '/^[0-9]+: / {print $2}' | awk '{print $1}' | sed 's/@.*//')

  if [ -z "$interfaces" ]; then

    sleep 1

    continue

  fi

  for interface in $interfaces; do

    if [[ $interface == eth* ]]; then

      break 2

    fi

    if [[ $interface == k-p-* ]]; then

      egress_file="/dockerstartup/.egress_status"

      while [ ! -f "$egress_file" ]; do

        sleep 1

      done

      egress_status=$(cat $egress_file)

      if [ "$egress_status" == "ready" ]; then

        break 2

      fi

      if [ "$egress_status" == "error" ]; then

        echo "Failed to establish egress gateway. Exiting..."

        exit 1

      fi

    fi

  done

  sleep 1

done
silmarine commented 3 months ago

you mean the same command that you can use to display ip addresses? I have that on a custom linuxserver image and that one still gets the error. Me using the command in the workspace: image

Error after deleting that session: image

djarbz commented 3 months ago

Must be unrelated, the IP command bug is fixed, but I was also getting these errors so I thought they might be related.

LinuxServer-CI commented 2 months ago

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

thelamer commented 1 month ago

Those errors are not fatal, we put the minimum amount of logic in the container to facilitate a smooth Kasm experience, but we do not put everything. Stuff like session recording services and key logging that are needed in the enterprise will not be added to our base for example. These hooks are there for image builders mostly and can absolutely be added if needed, but I do not think we need exit 0 place holders in place, seems more to me that upstream should check if the file exists before trying to execute it.

silmarine commented 1 month ago

That makes sense to me. As long as it's not an actual problem and just Kasm complaining unnecessarily then I can ignore it.

LinuxServer-CI commented 3 weeks ago

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.