I am trying to run jupyterhub on an Ubuntu 20.04 LTS server. My idea is to run python/jupyterhub in a conda virtual environment as a system service. As I want to be able to limit the resources available to individual users I installed the systemdspawner.
After installing everything and starting the jupyterhub service I can login through my web browser. However, when trying to start the server the spawner stucks and after a while I get an error message saying "Spawn failed: Timeout"
in journalctl I can see the following messages:
User logged in: me 302 POST /hub/login?next= -> /hub/spawn (me#::ffff:[my IP address]) 59.42ms
Adding role server to token: <APIToken('93c8...', user='me', client_id='jupyterhub')
Creating oauth client jupyterhub-user-me
pam_loginuid(login:session): Error writing /proc/self/loginuid: Operation not permitted
pam_loginuid(login:session): set_loginuid failed
pam_unix(login:session): session opened for user me by (uid=0)
Failed to open PAM session for me: [PAM Error 14] Cannot make/remove an entry for the specified session
Disabling PAM sessions from now on. user:me
Unit jupyter-me-singleuser in a failed state. Resetting state.
Disclaimer: My Jupyter/Python installation is replacing an former installation that was setup by someone else and got messed up a bit during time. I tried to remove everything related and start with a clean installation from scratch. However, as I had very little documentation about the old setup there is a certain risk that there might be some left-overs of the previous installation that may cause trouble.
Any ideas?
Solved it out myself. In the end the PAM related messages seem to be non-critical and were not related to the timeout at all. Instead I found a mistake in /etc/systemd/system/jupyterhub.service, where the PATH variable was not including the bin directory of my miniconda installation.
Related
I'm unable to login to my RStudio Server installed on a ubuntu container. I've created the accounts and changed the user ids.
Screenshot of error:
Looking at /var/log/syslog there are Operation not Permitted errors on temporary files under /tmp/rstudio-rsessions - I just had to change the ownership or delete the files user-d and user-d.pid.
I am getting started with Ethereum and building a Dapp (what the hell does this mean by the way?). On the basic installation of the application (https://github.com/ethereum/wiki/wiki/Dapp-using-Meteor#connect-your-%C3%90app), I get this error upon attempting to connect.
geth --rpc --rpccorsdomain "http://localhost:3000"
I0804 23:48:24.987448 ethdb/database.go:82] Alloted 128MB cache and 1024 file handles to /Users/( . )Y( . )/Library/Ethereum/chaindata
Fatal: Could not open database: resource temporarily unavailable
I literally just got started, I set up ethereum through homebrew and made an account with geth. Can't get past right here.
Thank you!
Your geth client is already running in the background. You can attach to it by typing:
$ geth attach
in your command line. This will allow you to run commands on the geth client console.
I had an application in my shiny-server working fine some months ago. Today I returned to it and got the most curious error. Whenever I try to access it, I just get this massage
An error has occurred
The application failed to start.
The application exited during initialization.
Now the natural step would be to go check the log of this error, right? But the Logs created by this error are just empty, 0 bytes. So I am really puzzled why this is happening, I also tried to run the shiny sample apps and get the same error, but the server itself seems to be running just fine.
I know this is sort of a vague question, but honestly I don't know what other info could I put here due to the empty logs and it could be that someone came across a similar issue
Shiny Server defaults to sanitised error logs, which is not useful in this case. You can change this behaviour by adding the line sanitize_errors off; to /etc/shiny-server/shiny-server.conf. You may need to restart Shiny Server to see the effect.
To open /etc/shiny-server/shiny-server.conf:
sudo nano /etc/shiny-server/shiny-server.conf
To restart Shiny Server:
sudo restart shiny-server
This should give you the verbose error messages you want.
This is the first time I have tried to connect R and Tableau.
I have downloaded and installed Rserve successfully but every time I try to start Rserve is get this warning:
Starting Rserve...
"C:\Users\SIMON~1.HAR\DOCUME~1\R\WIN-LI~1\3.1\Rserve\libs\x64\Rserve.exe"
Warning message:
running command '"C:\Users\SIMON~1.HAR\DOCUME~1\R\WIN-LI~1\3.1\Rserve\libs\x64\Rserve.exe" ' had status 127
I have been searching for days and couldn't find any fix.
The Rserve() function is trying to start an application (Rserve.exe) and failed. There's a couple of things you can do.
Go to the "C:\Users\SIMON~1.HAR\DOCUME~1\R\WIN-LI~1\3.1\Rserve\libs\x64\" file directory and try loading the exe yourself, troubleshoot from there.
use the run.Rserve() function instead of Rserve(). This will use your current R session to start the Rserve server. This means the exe doesn't need to be run. This worked well for me because I am working in an environment where I don't enough privileges to run the exe. It does mean that your R session can't do anything else while the server is running, but you can always load up 2 sessions at the same time.
Using the following for just connection pooling no master_slave or replication: rhel 6, postgresql 9.1.9, & pgpool-II 3.1.3 (also tried 3.2.5)
Followed solution suggested in http://www.pgpool.net/pipermail/pgpool-general/2013-May/001773.html
After following the instructions for MD5 I also tried setting both pg_hba.conf and pool_hba.conf to trust for local and subnet, but still get the following error when attempting to connect to the pool locally:
ERROR: "MD5" authentication with pgpool failed for user foo
Tried locally on Fedora 18 with pg9.2 and pgpool from Fedora repo and worked right out of the box.
At the end of all routes suggested everywhere I could find.
Help would be greatly appreciated.
After having hit the same problem the solution was to change ownership of the pool_passwd file to postgres.
Even though this file has a 644 permission, if owner isn't postgres you'll always get the aforementioned error. I guess this file's owner and the user running pgpool must match.
I'm running PosgreSQL 9.2 and pgpool-II 3.3.2, BTW.