Phusion Passenger: Error executing action `restart` on resource 'service[passenger]' - nginx

I am using Nginx+Passenger.
I was trying to upgrade Phusion passenger from 5.0.29 to 5.1.11. Everything was fine except restarting of the passenger is throwing an error as shown in the image.
I tried to again run the chef-client, its restarted properly. But I have to run the chef-client twice which I cannot afford.
Until the completion of 2nd-time chef-client, my website is down.
Recipes details:
service "passenger" do
supports :status => true, :restart => true, :reload => true
action [ :enable, :start ]
end
Any Idea why it is happening.
Thanks

Try invoking /etc/init.d/passenger restart and see the result. In case you get the same error, the problem is that it does not support that operation.
Also, as a workaround try notifying to the resource stop start instead of restart, it will do the trick.
Finally, do you restart the service on each chef-client run? Is this really needed? It will imply a small downtime every ~30 minutes

For me, failed restarts (after a passenger upgrade) was related to this issue.
Try with downgrading passenger to 5.1.7 (or wait for the 5.1.12 release)

Related

pm2 time logging - can't see time, only date

Maybe someone could help, why having this configuration:
pm2 start npm --name simple-app --log-date-format "YYYY-DD-MM HH:mm:ss.SSS" -- start
I see only date of logs? I can't see exact time:
Binding this server to an open connection can result in compromising your application or
computer. Using a different host than the one passed to the "--host" flag might result in
websocket connection issues. You might need to use "--disableHostCheck" if that's the
case.2022-22-11:
2022-22-11: Warning: Running a server with --disable-host-check is a security risk. See https://medium.com/webpack/webpack-dev-server-middleware-security-issues-1489d950874a for more information.2022-22-11:
2022-22-11:
Compiling #angular/core : es2015 as esm2015
version of pm2 - 5.2.2, but I noticed the same on older version in my case.

jupyterhub fails to spawn server with systemdspawner

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.

Pintos - UserProg all tests fail is_kernel_vaddr()

I am doing the Pintos project on the side to learn more about operating systems. I had tons of devops trouble at first with it not running well on an 18.04 Ubuntu droplet. I am now running it on the VirtualBox image that UCCS tells students to download for pintos.
I finished project 1 and started to map out my solution to project 2. Following the instructions to create a file I ran
pintos-mkdisk filesys.dsk --filesys-size=2
pintos -- -f -q
but am getting error
Kernel PANIC at ../../threads/vaddr.h:87 in vtop(): assertion
`is_kernel_vaddr (vaddr)' failed.
I then tried running make check (all the tests). They are all failing for the same reason.
Am I missing something? Is there something I need to implement to fix this? I reread the instructions and didnt see anything?
Would appreciate help!
Thanks
I had a similar problem. My code for Project 1 ran fine, but I could not format the filesystem for Project 2.
The failure for me came from the following call chain:
thread_init() -> ... -> thread_schedule_tail() -> process_activate() -> pagedir_activate() -> vtop()
The problem is that init_page_dir is still NULL when pagedir_activate() is called. init_page_dir should have been initialized in paging_init() but this is called after thread_init().
The root cause was that my scheduler was being called too early, i.e. before the call to thread_start(). The reason for my problem was that I had built in a call to thread_yield() upon completion of every call to lock_release() which makes sense from a priority donation standpoint. Unfortunately, locks are used prior to the scheduler being ready! To fix this, I installed a flag called threading_started that bails in the first line of my thread_block() and thread_yield() functions if thread_start() has not yet been called.
Good luck!

Shiny failed to start

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.

Meteor Velocity; using CLI getting timeout

Simple tests are timing-out intermittently on CircleCi. This only happens on CircleCi, locally on OSX, all testing is fine. Anyone having success with CircleCi specifically?
Running tests should be straightforward, but no one at CircleCI, or at the velocity forum have been able to solve this.
I've used the simple example tests from sanjo:jasmine. Intermittently, velocity hangs and goes to timeout. No errors. Nothing informative in logs. Strangely it did work once on CircleCi, and then never again.
The test command is simply:
meteor --test
The output I get doesn't print any tests:
stream error Network error: ws://localhost:3000/websocket: connect ECONNREFUSED
[[[[[ ~/app ]]]]]
=> Started proxy.
=> Started MongoDB.
=> Started your app.
=> App running at: http://localhost:3000/
In the .meteor/local/log/jasmine-client-unit.log this is the last line:
Chrome 38.0.2125 (Linux): Executed 0 of 0^[[32m SUCCESS^[[39m (0 secs / 0 secs)
^[[1A^[[2KChrome 38.0.2125 (Linux): Executed 0 of 0^[[31m ERROR^[[39m (0.023 secs / 0 secs)
I confirmed that the versions are the same Meteor 1.03.2, Node 0.10.33, Phantomjs 2.0.0, Chrome 40. Sorry that I can't provide a reproducible repository, it's a very intermittent error likely related to environment.
Try meteor --test --once
The once might be the reason it's not finishing up
edit
It turns out that jasmine end to end testing recommends webdriver as well. So my advice below should still apply for jasmine.
/edit
What framework? If it is cucumber, the issue is the phantomjs version that gets installed doesn't install the right binary for some reason.
For that reason, in CI, you need to install phantom and set the path as an environment variable.
npm install -g phantomjs
export PHANTOM_PATH=`which phantomjs`
This will tell webdriver to use your path of the correctly installed binary instead of the wrong version.
We should really just fix Cucumber.js to not fail silently.
The other error you are seeing about websockets is just --test not connecting right on startup, it doesn't affect anything.

Resources