When I try to upload an image file to the default image datastore (ID 1), Sunstone service is restarted resulting in a failed upload. I see the following at the sunstone logs:
Jun 10 19:53:15 one-vm-ubuntu opennebula-sunstone[3259]: == Sinatra has ended his set (crowd applauds)
Jun 10 19:53:20 one-vm-ubuntu opennebula-sunstone[3259]: /usr/lib/ruby/3.0.0/tempfile.rb:238:in `size': No such file or directory @ rb_file_s_size - /var/tmp/thin-body20240610-3259-4a7tg9 (Errno::ENOENT)
Jun 10 19:53:20 one-vm-ubuntu opennebula-sunstone[3259]: #011from /usr/lib/ruby/3.0.0/tempfile.rb:238:in `size'
Jun 10 19:53:20 one-vm-ubuntu opennebula-sunstone[3259]: #011from /usr/share/one/gems-dist/gems/thin-1.8.2/lib/thin/request.rb:104:in `finished?'
Jun 10 19:53:20 one-vm-ubuntu opennebula-sunstone[3259]: #011from /usr/share/one/gems-dist/gems/thin-1.8.2/lib/thin/request.rb:78:in `parse'
Jun 10 19:53:20 one-vm-ubuntu opennebula-sunstone[3259]: #011from /usr/share/one/gems-dist/gems/thin-1.8.2/lib/thin/connection.rb:39:in `receive_data'
Jun 10 19:53:20 one-vm-ubuntu opennebula-sunstone[3259]: #011from /usr/share/one/gems-dist/gems/eventmachine-1.2.7/lib/eventmachine.rb:195:in `run_machine'
Jun 10 19:53:20 one-vm-ubuntu opennebula-sunstone[3259]: #011from /usr/share/one/gems-dist/gems/eventmachine-1.2.7/lib/eventmachine.rb:195:in `run'
Jun 10 19:53:20 one-vm-ubuntu opennebula-sunstone[3259]: #011from /usr/share/one/gems-dist/gems/thin-1.8.2/lib/thin/backends/base.rb:75:in `start'
Jun 10 19:53:20 one-vm-ubuntu opennebula-sunstone[3259]: #011from /usr/share/one/gems-dist/gems/thin-1.8.2/lib/thin/server.rb:162:in `start'
Jun 10 19:53:20 one-vm-ubuntu opennebula-sunstone[3259]: #011from /usr/share/one/gems-dist/gems/rack-2.2.8/lib/rack/handler/thin.rb:22:in `run'
Jun 10 19:53:20 one-vm-ubuntu opennebula-sunstone[3259]: #011from /usr/share/one/gems-dist/gems/sinatra-3.1.0/lib/sinatra/base.rb:1650:in `start_server'
Jun 10 19:53:20 one-vm-ubuntu opennebula-sunstone[3259]: #011from /usr/share/one/gems-dist/gems/sinatra-3.1.0/lib/sinatra/base.rb:1589:in `run!'
Jun 10 19:53:20 one-vm-ubuntu opennebula-sunstone[3259]: #011from /usr/lib/one/sunstone/sunstone-server.rb:1247:in `<main>'
Jun 10 19:53:20 one-vm-ubuntu opennebula-sunstone[3259]: 2024-06-10 19:39:11 +0000 Thin web server (v1.8.2 codename Ruby Razor)
Jun 10 19:53:20 one-vm-ubuntu opennebula-sunstone[3259]: 2024-06-10 19:39:11 +0000 Maximum connections set to 1024
Jun 10 19:53:20 one-vm-ubuntu opennebula-sunstone[3259]: 2024-06-10 19:39:11 +0000 Listening on 0.0.0.0:9869, CTRL+C to stop
Jun 10 19:53:20 one-vm-ubuntu opennebula-sunstone[3259]: 2024-06-10 19:53:15 +0000 Stopping ...
Jun 10 19:53:20 one-vm-ubuntu systemd[1]: opennebula-sunstone.service: Main process exited, code=exited, status=1/FAILURE
Jun 10 19:53:20 one-vm-ubuntu systemd[1]: opennebula-sunstone.service: Failed with result 'exit-code'.
Jun 10 19:53:20 one-vm-ubuntu systemd[1]: opennebula-sunstone.service: Consumed 2min 32.159s CPU time.
Jun 10 19:53:25 one-vm-ubuntu systemd[1]: opennebula-sunstone.service: Scheduled restart job, restart counter is at 1.
Jun 10 19:53:25 one-vm-ubuntu systemd[1]: Stopped OpenNebula Web UI Server.
Jun 10 19:53:25 one-vm-ubuntu systemd[1]: opennebula-sunstone.service: Consumed 2min 32.159s CPU time.
This is a new default Opennebula installation of 6.8.0 CE on a Ubuntu 22.04 VM (8GB memory, 4 CPU cores, 100 GB disk) and I am accessing the UI at http://IP:9869. I have checked that I have plenty of space at /var/tmp. The issue seems to be encountered with bigger files since I was able to upload a 250MB ISO file. I did not face this issue when I had installed Opennebula directly at the baremetal.
I am out of ideas what else to check. Appreciate any help.
Versions of the related components and OS (frontend, hypervisors, VMs):
Opennebula 6.8.0 running within Ubuntu 22.04 VM.
Host OS: Ubuntu 22.04 64 bit 5.15.0-112-generic
Hypervisor: KVM
Steps to reproduce:
Upload ISO or disk image through the Sunstone UI logged in as the default oneadmin user.
Current results:
Sunstone is restarted and the user needs to login again. The upload session is lost.
Expected results:
One should be able to upload larger image files, provided there is disk space.
Hi Alberto, I am not using apache or passenger. I am accessing Sunstone from its plain port http://IP:9869. Let me know if I can find out anything else. Thanks.
I tested the same default setup at a clean Debian11 installation and I get the same consistent error when I try to upload an ISO file at the default datastore:
Jun 17 07:22:27 debian11-one opennebula-sunstone[1461]: /usr/lib/ruby/2.7.0/tempfile.rb:226:in `size': No such file or directory @ rb_file_s_size - /var/tmp/thin-body20240617-1461-bkufps (Errno::ENOENT)
Just to repeat, that I am accessing directly Sunstone at port 9869 without any reverse proxy or intermediaries.
[Unit]
Description=OpenNebula Web UI Server
After=syslog.target network.target
After=opennebula.service
Wants=opennebula-novnc.service
AssertFileNotEmpty=/var/lib/one/.one/sunstone_auth
[Service]
Type=simple
Group=oneadmin
User=oneadmin
AmbientCapabilities=CAP_NET_BIND_SERVICE
ExecStartPre=-/usr/sbin/logrotate -f /etc/logrotate.d/opennebula-sunstone -s /var/lib/one/.logrotate.status
ExecStartPre=-sh 'gzip -9 /var/log/one/sunstone.log-* &'
ExecStart=/usr/bin/ruby /usr/lib/one/sunstone/sunstone-server.rb
ReadWriteDirectories=/var/lib/one /var/log/one/
ReadOnlyDirectories=-/var/lib/one/remotes
InaccessibleDirectories=-/var/lib/one/datastores
InaccessibleDirectories=-/var/lib/one/.ssh
InaccessibleDirectories=-/var/lib/one/.ssh-oneprovision
ReadWriteDirectories=/var/tmp
PrivateTmp=no
NoNewPrivileges=yes
PrivateDevices=yes
# ProtectSystem=strict is not known by old systemd, so we set
# full everywhere, and override by strict only where supported.
ProtectSystem=full
ProtectSystem=strict
ProtectHome=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectKernelLogs=yes
StartLimitInterval=60
StartLimitBurst=3
Restart=on-failure
RestartSec=5
SyslogIdentifier=opennebula-sunstone
[Install]
WantedBy=multi-user.target
It is the default one. I tried also to change the temp dir (/var/tmp) both at suntone config and systemd service but had same results. Thanks for assisting.
Seems that I replaced the issue with another one, as I need to find out how to make the nginx setup work as sunstone is complaining that it cannot reach fireedge public endpoint.
And configured the FireEdge public port to listen to 2646. Seems now the VNC access through guacamole is working again. The only issue is SPICE is now broken but I will open another topic for this.