Skip to content
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

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

Open
1 task done
silmarine opened this issue Apr 30, 2024 · 14 comments

Comments

@silmarine
Copy link

silmarine commented Apr 30, 2024

Is there an existing issue for this?

  • I have searched the existing issues

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''
Copy link

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
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

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
Copy link

S0ulDrag0n commented Jul 5, 2024

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

Edit: Seems to only occur with Linuxserver images.

@djarbz
Copy link

djarbz commented Jul 26, 2024

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

/kasminit: line 79: ip: command not found

@djarbz
Copy link

djarbz commented Jul 26, 2024

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

@djarbz
Copy link

djarbz commented Jul 26, 2024

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
Copy link
Author

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
Copy link

djarbz commented Aug 16, 2024

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
Copy link
Contributor

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
Copy link
Member

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
Copy link
Author

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Issues
Development

No branches or pull requests

5 participants