I just started with SuperCollider (version 3.6.6 on 64 bit ubuntu 16.04)
When I start my server (the default one), all other streaming stops working (youtube, spotify, etc.)
Even after I quit they still do not work
I tried s.quit;, s.freeAll;, 'stop', s.killAll; closing the program etc. (various comiations of these in various order).
Additionally, I tried ps ax | grep scsynth and killed that pid, but the process keeps respawning constantly (even if I do not kill it, if I run ps ax | grep scsynth twice, I get a new pid)
Any ideas how I can free up whatever the thing is that SC has taken from my streaming platforms that they need (maybe Jack, maybe someting else, I'm not sure)?
I ran
killall pulseaudio
and now I can play youtube, spotify etc even while my supercollider server is running and playing music
Granted, I do not understand why this 'fixed' my issue. I just copied it from this https://askubuntu.com/questions/1033743/no-sound-on-ubuntu-18-04-spotify-and-youtube-dont-work-either/1034813 without thinking it would work
Related
I started a node script inside WebStorm once. It is a VueJS application. It is running on localhost:5000. When I open it inside chrome, I can see that it first is not responding, and then it suddenly loads. That tells me that the process is always restarting and inside a loop.
When I run ps aux | grep node , I can see the process quickly changing the process ID. That confirms my observation. If I try to kill the process it tells me that there is no process with that ID because it restarted that quickly. The process also is starting when reboot the computer. I also completely uninstalled NodeJS from my computer, but strangely it is starting anyways. I'm on macOS and I don't know what I could try anymore.
ps aux | grep node output:
2959 0,0 0,0 4268464 740 s000 S+ 3:47pm 0:00.00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn --exclude-dir=.idea --exclude-dir=.tox node
I don't have enough reputation to leave a comment on your question, so I'm writing here.
It seems like you're application somehow registered in the service which happened to me as well. Mine was CentOS7.
You can check if it's added into service and run automatically whenever the machine is on. The command is Linux ones, so I'm not sure whether it's gonna work on MacOS as well.
//check list
chkconfig --list
//turn off the automatic start
chkconfig [your application name] off
If changing service config by using above commands did not work, you can search for the Mac Service Script. I think service shell script are different. Again, my case was on CentOS7.
Hope it helps.
I have a VPS with firewall and security notices enabled. I keep getting emails like this:
Time: Wed Jun 19 19:01:54 2019 -0500
Account: user
Resource: Process Time
Exceeded: 7248 > 3600 (seconds)
Executable: /opt/cpanel/ea-php72/root/usr/sbin/php-fpm
Command Line: php-fpm: pool domain_com
PID: 16374 (Parent PID:9915)
Killed: No
So for some reason with this example I have a script that has apparently been running for 2+ hours non-stop. I don't have anything that should be doing that.
I'm getting notices like this quite often. How can I use this info to track down what specifically is causing this?
Any information would be greatly appreciated. Thanks!
You can track which the exact process with the process ID mentioned.
lsof -p 16374
The alert which you are getting is from the LDF which is installed as a part of CSF. I think its normal for cPanel with php_fpm to have the process php_fpm run this long.
You can add the php-fpm to csf.pignore file to stop this warning.
You can also refer the below cPanel fourm thread.
https://forums.cpanel.net/threads/lfd-excessive-resource-usage-normal-for-php-fpm.592583/
To get more information on processes, I would use the Htop tool. This is a great article for learning about how to manage processes using htop and ps
Lsof (List open files) will tell you more information about what files the process is using.
You can get htop and lsof with
sudo apt install htop lsof -y
This article indicates that :
That message comes from the third-party CSF/LFD application and indicates a PHP-FPM process was running longer than the maximum time configured for the CSF/LFD detection period. It shows the process was not killed, thus you should not have traffic loss.
So you might want to check the PHP-FPM error log for the account in-question to see if you notice any particular error messages. It's located at:
/home/$username/logs/domain_tld.php.error.log
It looks like your specific issue has not been resolved on that form. So, you might want to try strace. It handles watching system calls made by a given process including all read-write operations and os function calls. You can activate it on the command line before the program you want to track or attach to a running process by hitting s on a process selected in htop.
https://yarnpkg.com/en/docs/cli/
Is there a way to stop what is started from the command "yarn run"? Is my only option to lookup the process number and call kill on it?
The usual way ctrl-c should work. If it doesn't work, than you have bug in the script. The script's author missed handler for shutdown (SIGINT/SIGTERM/etc).
I had a similar issue having it running after ctl+c and then I thought, maybe it is just running on the cache
so went to http://localhost:3000/
ctrl+F5
which forces refresh without cache showed me that the actual project wasn't really running anymore!
;)
*hadn't it worked I would have had to sudo kill the 3000 port
I know this is a well-answered question. However, it behaved once very strange when I was running a sample React code which was auto-created by the create-react-app CLI, on my Windows 10.
After hitting Ctrl+C, which is the most suggested standard way to stop the yarn run, though I got back the command prompt, there was a ghost process lingering around there, which was still actively listening to 3000(default) port, and localhost:3000 was working as normal.
So finally this is how I fixed it:
netstat -ano | grep ":3000" (yeah, I ran this from my git-bash instead of command prompt!)
Noted down the PID of the line where it says LISTENING on 3000
Pressed Ctrl+Shift+Esc to open the Task Manager
Went to the Process tab
Right clicked on one of the headings, say Name
Selected PID --> This added the PID column to the display
Located the PID in question
Right clicked on it and clicked "End task"
Luckily Windows knew how to kill that misbehaving, ghost process and the port became free for me.
NOTE: Prior to the above-mentioned steps, I tried to kill that PID from git-bash using the famous (or notorious as per its meaning?? >8)) kill -9 command. It was responding back with no such PID msg, however netstat -ano was clearly displaying the PID and browser was proving that the ghost process is up and alive!!
I got a live server running nodejs chat app. I connect to server using terminal on mac. I start the server by typing server.js.
the problem is, my terminal always hung after one hour running, and there are no error outputs. when it hangs, I press ctrl+c I got the message [process completed].
note: My terminal runs node apps locally without any problems.
And my current chat app run well when I initiate it with WinSCP in windows platform.
Try launching your node process on the remote server using a tool like nohup.
bash$ nohup /path/to/node server.js > out.txt 2> err.txt &
[1] 53032
# Now you can logout of the remote server without
# killing the "node" process and chat server.
[Edit]
Note that the number printed by "nohup" (e.g. 53032) is the id of detached process, so if you need to terminate it you can do something like "kill -9 53032". If you forgot to record that number then you'll have to find it by using a program such as "ps"; for example, you can run "ps auxwww | grep node" (the flags will vary depending on your system) and you'll see output similar to this:
maerics 81694 0.6 0.5 2543604 21216 s000 S+ 10:34AM 0:09.45 /Users/maerics/opt/node/node server.js
In this example, on my system, the number in the second column is the process id.
Since I install pending updates for my Ubuntu server as soon as possible, I have to restart my linux server quite often. I'm running an webapp on that server and would like to warn my users about the pending restart. Right now, I do this manually, adding an announcement before the restart, give them some time to finish their work, restart and remove the announcement.
I hope, shutdown -r +60 writes an file with all the information about the restart, which I can check on every access. Is there such a file? Would prefer a file in a virtual file system like /proc for performance reasons...
I'm running Ubuntu 10.04.2 LTS
If you are using systemd, the following command shows the scheduled shutdown info.
cat /run/systemd/shutdown/scheduled
Example of output:
USEC=1636410600000000
WARN_WALL=1
MODE=reboot
As remarked in a comment by #Björn, USEC is the timestamp in micro seconds.
You can convert it to a human friendly format dropping the last 6 figures and using date like this:
$ date -d #1636410600
Mon Nov 8 23:30:00 CET 2021
The easiest solution I can envisage means writing a script to wrap the shutdown command, and in that script create a file that your web application can check for.
As far as I know, shutdown doesn't write a file to the underlying files system, although it does trigger broadcast messages warning of the shutdown, which I suppose you could write a program to intercept .. but the above solution seems the easiest.
Script example:
shutdown.bsh
touch /somefolder/somefile
shutdown -r $1
then check for 'somefile' in your web app.
You'd need to add a startup link that erased the 'somefile' otherwise it would still be there when the system comes up and the web app would always be telling your users it was about to shut down.
You can simply check for running shutdown process:
if ps -C shutdown > /dev/null; then
echo "Shutdown is pending"
else
echo "Shutdown is not scheduled"
fi
For newer linux distributions versions you might need to do:
busctl get-property org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager ScheduledShutdown
The method of how shutdown works has changed
Tried on:
- Debian Stretch 9.6
- Ubuntu 18.04.1 LTS
References
Check if shutdown schedule is active and when it is
The shutdown program on a modern systemd-based Linux system
You could write a daemon that does the announcement when it catches the SIGINT / SIGQUIT signal.