Dear experts,
I recently installed shiny-server (shiny-server-1.5.19.995-amd64.deb) on a Ubuntu 20.10 (digitalocean droplet).
I closely followed Dean Attali's blog entry for setup How to get your very own RStudio Server and Shiny Server with DigitalOcean
The droplet ran all apps in /srv/shiny-server flawlessly for ~24 hours, but I now get the following error when accessing the default index.html in srv/shiny-server:
An error has occurred
Invalid application configuration.
ENOENT: no such file or directory, stat '/srv/shiny-server/index.html'
see here: https://app.protectlab.org/shiny/
I also uploaded some of my own apps, which ran nicely, but now only the UI is displayed; shiny does not seem to start, e.g.: Metapsy | Psychotherapy for Depression
This is the output I get running sudo systemctl status shiny-server (non-root user with sudo permissions)
● shiny-server.service - ShinyServer
Loaded: loaded (/lib/systemd/system/shiny-server.service; enabled; preset: enabled)
Active: active (running) since Sat 2022-11-05 12:50:17 UTC; 21h ago
Main PID: 12195 (shiny-server)
Tasks: 11 (limit: 4661)
Memory: 38.4M
CPU: 2.333s
CGroup: /system.slice/shiny-server.service
└─12195 /usr/lib/shiny-server/ext/node/bin/shiny-server /usr/lib/shiny-server/lib/main.js
Nov 05 12:50:17 shiny-3000 systemd[1]: Started ShinyServer.
Nov 05 12:52:29 shiny-3000 su[13033]: (to shiny) root on none
Nov 05 12:52:29 shiny-3000 su[13033]: pam_unix(su-l:session): session opened for user shiny(uid=997) by (uid=0)
Nov 05 12:53:32 shiny-3000 su[13063]: (to shiny) root on none
Nov 05 12:53:32 shiny-3000 su[13063]: pam_unix(su-l:session): session opened for user shiny(uid=997) by (uid=0)
Nov 06 00:11:31 shiny-3000 su[15314]: (to shiny) root on none
Nov 06 00:11:31 shiny-3000 su[15314]: pam_unix(su-l:session): session opened for user shiny(uid=997) by (uid=0)
Nov 06 10:21:52 shiny-3000 su[16912]: (to shiny) root on none
Nov 06 10:21:52 shiny-3000 su[16912]: pam_unix(su-l:session): session opened for user shiny(uid=997) by (uid=0)
/opt/shiny-server seems to have been deleted.
This is my shiny-server.config:
# Instruct Shiny Server to run applications as the user "shiny"
run_as shiny;
# Define a server that listens on port 3838
server {
listen 3838;
# Define a location at the base URL
location / {
# Host the directory of Shiny Apps stored in this directory
site_dir /srv/shiny-server;
# Log all Shiny output to files in this directory
log_dir /var/log/shiny-server;
# When a user visits the base URL rather than a particular application,
# an index of the applications available in this directory will be shown.
directory_index on;
}
}
This is what I have in /etc/nginx/sites-enabled/default/:
##
# You should look at the following URL's in order to grasp a solid understanding
# of Nginx configuration files in order to fully unleash the power of Nginx.
# https://www.nginx.com/resources/wiki/start/
# https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/
# https://wiki.debian.org/Nginx/DirectoryStructure
#
# In most cases, administrators will remove this file from sites-enabled/ and
# leave it as reference inside of sites-available where it will continue to be
# updated by the nginx packaging team.
#
# This file will automatically load configuration files provided by other
# applications, such as Drupal or Wordpress. These applications will be made
# available underneath a path with that package name, such as /drupal8.
#
# Please see /usr/share/doc/nginx-doc/examples/ for more detailed examples.
##
# Default server configuration
#
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
server {
listen 80 default_server;
listen [::]:80 default_server;
# SSL configuration
#
# listen 443 ssl default_server;
# listen [::]:443 ssl default_server;
#
# Note: You should disable gzip for SSL traffic.
# See: https://bugs.debian.org/773332
#
# Read up on ssl_ciphers to ensure a secure configuration.
# See: https://bugs.debian.org/765782
#
# Self signed certs generated by the ssl-cert package
# Don't use them in a production server!
#
# include snippets/snakeoil.conf;
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_name _;
location /shiny/ {
proxy_pass http://127.0.0.1:3838/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
rewrite ^(/shiny/[^/]+)$ $1/ permanent;
}
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
# pass PHP scripts to FastCGI server
#
#location ~ \.php$ {
# include snippets/fastcgi-php.conf;
#
# # With php-fpm (or other unix sockets):
# fastcgi_pass unix:/run/php/php7.4-fpm.sock;
# # With php-cgi (or other tcp sockets):
# fastcgi_pass 127.0.0.1:9000;
#}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
# deny all;
#}
}
# Virtual Host configuration for example.com
#
# You can move that to a different file under sites-available/ and symlink that
# to sites-enabled/ to enable it.
#
#server {
# listen 80;
# listen [::]:80;
#
# server_name example.com;
#
# root /var/www/example.com;
# index index.html;
#
# location / {
# try_files $uri $uri/ =404;
# }
#}
server {
# SSL configuration
#
# listen 443 ssl default_server;
# listen [::]:443 ssl default_server;
#
# Note: You should disable gzip for SSL traffic.
# See: https://bugs.debian.org/773332
#
# Read up on ssl_ciphers to ensure a secure configuration.
# See: https://bugs.debian.org/765782
#
# Self signed certs generated by the ssl-cert package
# Don't use them in a production server!
#
# include snippets/snakeoil.conf;
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_name app.protectlab.org; # managed by Certbot
location /shiny/ {
proxy_pass http://127.0.0.1:3838/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
rewrite ^(/shiny/[^/]+)$ $1/ permanent;
}
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
# pass PHP scripts to FastCGI server
#
#location ~ \.php$ {
# include snippets/fastcgi-php.conf;
#
# # With php-fpm (or other unix sockets):
# fastcgi_pass unix:/run/php/php7.4-fpm.sock;
# # With php-cgi (or other tcp sockets):
# fastcgi_pass 127.0.0.1:9000;
#}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
# deny all;
#}
listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/app.protectlab.org/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/app.protectlab.org/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = app.protectlab.org) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80 ;
listen [::]:80 ;
server_name app.protectlab.org;
return 404; # managed by Certbot
}
I'm a total nginx/ubuntu noob - could this have something to do with lack of permissions? (i did follow the instructions in DA's blog closely though).
Any help would be greatly appreciated!