I want to disable the automatic time update mechanism of raspberry pi 3 and then set a specific time for it.
To do so, I disable ntp on the raspbian using the following code:
sudo timedatectl set-ntp 0
And after this, the ntp was disabled. But when I set the specific time again, after some minutes, the time gets updated automatically again.
How do I fix this problem?
If you are using raspian on your rpi3 you can normally disable ntp by executing:
sudo systemctl stop ntp.service
sudo systemctl disable ntp.service
and if you have a hardware real-time clock on the i2c bus also execute:
sudo systemctl stop fake-hwclock.service
sudo systemctl disable fake-hwclock.service
Related
I've installed Redis version 3.2.12 on one node CentOS 7 of a cluster with Cloudera Manager 6.3 and my redis never stop.
Everything is on default, I just added the password, but that has no effects because I can't restart. Option daemonize is no
My instalation was:
sudo yum -y install redis
sudo service redis start
When I type redis-cli, CLI starts normally at 127.0.0.1:6379. When I try shutdown, the console shows 'not connected', but with lsof -i :6379 I can identify that some jobs die and return with another PID.
If I try to kill the redis jobs, it always return with another PID.
service redis stop Return 'Redirecting to /bin/systemctl stop redis.service' but has no effects.
If I try service redis restart then service redis status it returns:
redis.service: main process exited, code=exited, status=1/FAILURE
Unit redis.service entered failed state.
Someone can please help me as a way to debug or understand what is happening? It's my first time with Redis.
Not sure how is this related to celery...
CentOS 7 uses systemd so I would recommend stop using the service tool and start using the systemctl. First thing you should try is systemctl status redis to check the status of the Redis service. If it shows that for whatever reason it is down, then you should either check Redis logs, or use journalctl tool to look for system logs created by Redis.
I have seen that some installations might have redis as the command-line executable while some might have redis-server. So, please try one of these commands (one will work depending on the redis package):
sudo service redis-server restart
# OR
sudo service redis restart
If you have a newer Cent OS having systemctl installed, then try one of these:
sudo systemctl restart redis-server
# OR
sudo systemctl restart redis
I want to use Homebrew's version of Apache on my Mac so I can start/stop it as I please, so I've been trying all afternoon to stop and unload several httpd processes that are run by user _www on macOS 10.13.3 High Sierra without any luck.
See the screenshot attached, there are 6 httpd processes run by _www and the single process run under root (Homebrew service)
I've tried
sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist
which gives me an error:
/System/Library/LaunchDaemons/org.apache.httpd.plist: Could not find specified service
I've also tried tracking the process starting them down, switching user to _www (a no no) so I can see where it's being started and so far I'm having no luck.
I want to kill them all, and have them stay dead as right now they're conflicting with the server I'm actually trying to run. Anyone cleverer than me out there that knows how to kill this literal http demon?
https://stackoverflow.com/a/20439859/996338
Try this:
sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist
This will stop a running instance of Apache, and record that it should not be restarted. It records your preference in /private/var/db/launchd.db/com.apple.launchd/overrides.plist.
For a single session (meaning, between reboots), you can use sudo apachectl stop.
Using homebrew to install Redis but when I try to ping Redis it shows this error:
Could not connect to Redis at 127.0.0.1:6379: Connection refused
Note :
I tried to turn off firewall and edit conf file but still cannot ping.
I am using macOS Sierra and homebrew version 1.1.11
After installing redis, type from terminal:
redis-server
And Redis-Server will be started
I found this question while trying to figure out why I could not connect to redis after starting it via brew services start redis.
tl;dr
Depending on how fresh your machine or install is you're likely missing a config file or a directory for the redis defaults.
You need a config file at /usr/local/etc/redis.conf. Without this file redis-server will not start. You can copy over the default config file and modify it from there with
cp /usr/local/etc/redis.conf.default /usr/local/etc/redis.conf
You need /usr/local/var/db/redis/ to exist. You can do this easily with
mkdir -p /usr/local/var/db/redis
Finally just restart redis with brew services restart redis.
How do you find this out!?
I wasted a lot of time trying to figure out if redis wasn't using the defaults through homebrew and what port it was on. Services was misleading because even though redis-server had not actually started, brew services list would still show redis as "started." The best approach is to use brew services --verbose start redis which will show you that the log file is at /usr/local/var/log/redis.log. Looking in there I found the smoking gun(s)
Fatal error, can't open config file '/usr/local/etc/redis.conf'
or
Can't chdir to '/usr/local/var/db/redis/': No such file or directory
Thankfully the log made the solution above obvious.
Can't I just run redis-server?
You sure can. It'll just take up a terminal or interrupt your terminal occasionally if you run redis-server &. Also it will put dump.rdb in whatever directory you run it in (pwd). I got annoyed having to remove the file or ignore it in git so I figured I'd let brew do the work with services.
If after install you need to run redis on all time, just type in terminal:
redis-server &
Running redis using upstart on Ubuntu
I've been trying to understand how to setup systems from the ground up on Ubuntu. I just installed redis onto the box and here's how I did it and some things to look out for.
To install:
sudo apt-get install redis-server
That will create a redis user and install the init.d script for it. Since upstart is now the replacement for using init.d, I figure I should convert it to run using upstart.
To disable the default init.d script for redis:
sudo update-rc.d redis-server disable
Then create /etc/init/redis-server.conf with the following script:
description "redis server"
start on runlevel [23]
stop on shutdown
exec sudo -u redis /usr/bin/redis-server /etc/redis/redis.conf
respawn
What this is the script for upstart to know what command to run to start the process. The last line also tells upstart to keep trying to respawn if it dies.
One thing I had to change in /etc/redis/redis.conf is daemonize yes to daemonize no. What happens if you don't change it then redis-server will fork and daemonize itself, and the parent process goes away. When this happens, upstart thinks that the process has died/stopped and you won't have control over the process from within upstart.
Now you can use the following commands to control your redis-server:
sudo start redis-server
sudo restart redis-server
sudo stop redis-server
Hope this was helpful!
redis-server --daemonize yes
I have solved this issue by running this command.
This work for me :
sudo service redis-server start
Date: Dec 2021
There is a couple of reason for this error. I read one article to fix the issue for me. So I just summarize what to check one by one.
1 Check: Redis-Server not Started
redis-server
Also to run Redis in the background, the following command could be used.
redis-server --daemonize yes
2. Check: Firewall Restriction
sudo ufw status (inactive)
sudo ufw active (for making active it might disable ssh when first time active. So enable port 22 to access ssh.)
sudo ufw allow 22
sudo ufw allow 6379
3. Check: Resource usage
ps -aux | grep redis
4. Config setup restriction
sudo vi /etc/redis/redis.conf.
Comment the following line.
# bind 127.0.0.1 ::1
Note: It will be more difficult for malicious actors to make requests or gain access to your server. Make sure you're bound to correct IP address network.
Hope it helps someone. For more information read the following article.
https://bobcares.com/blog/could-not-connect-to-redis-connection-refused/
It's the better way to connect to your redis.
At first, check the ip address of redis server like this.
ps -ef | grep redis
The result is kind of " redis 1184 1 0 .... /usr/bin/redis-server 172.x.x.x:6379
And then you can connect to redis with -h(hostname) option like this.
redis-cli -h 172.x.x.x
Try this :
sudo service redis-server restart
Error connecting Redis on Apple Silicon( Macbook Pro M1 - Dec 2020), you have to just know 2 things:
Run the redis-server using a sudo will remove the server starting error
shell% sudo redis-server
For running it as a service "daemonize" it will allow you to run in the background
shell% sudo redis-server --daemonize yes
Verify using below steps:
shell% redis-cli ping
Hope this helps all Macbook Pro M1 users who are really worried about lack of documentation on this.
I was stuck on this for a long time. After a lot of tries I was able to configure it properly.
There can be different reasons of raising the error. I am trying to provide the reason and the solution to overcome from that situation. Make sure you have installed redis-server properly.
6379 Port is not allowed by ufw firewall.
Solution: type following command sudo ufw allow 6379
The issue can be related to permission of redis user. May be redis user doesn't have permission of modifying necessary redis directories. The redis user should have permissions in the following directories:
/var/lib/redis
/var/log/redis
/run/redis
/etc/redis
To give the owner permission to redis user, type the following commands:
sudo chown -R redis:redis /var/lib/redis
sudo chown -R redis:redis /var/log/redis
sudo chown -R redis:redis /run/redis
sudo chown -R redis:redis /etc/redis.
Now restart redis-server by following command:
sudo systemctl restart redis-server
Hope this will be helpful for somebody.
First you need to up/start the all the redis nodes using below command, one by one for all conf files.
#Note : if you are setting up cluster then you should have 6 nodes, 3 will be master and 3 will be slave.redis-cli will automatically select master and slave out of 6 nodes using --cluster command as shown in my below commands.
[xxxxx#localhost redis-stable]$ redis-server xxxx.conf
then run
[xxxxx#localhost redis-stable]$ redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1
output of above should be like:
>>> Performing hash slots allocation on 6 nodes...
2nd way to set up all things automatically:
you can use utils/create-cluster scripts to set up every thing for you like
starting all nodes, creating cluster
you an follow https://redis.io/topics/cluster-tutorial
Thanks
Actually you need to run "redis-server &" after instalation to start the service, when you only run "redis-server" the service runs in undetached mode. emphasis on "&"
I just had this same problem because I had used improper syntax in my config file. I meant to add:
maxmemory-policy allkeys-lru
to my config file, but instead only added:
allkeys-lru
which evidently prevented Redis from parsing the config file, which in turn prevented me from connecting through the cli. Fixing this syntax allowed me to connect to Redis.
Had that issue with homebrew MacOS the problem was some sort of permission missing on /usr/local/var/log directory see issue here
In order to solve it I deleted the /usr/local/var/log and reinstall redis brew reinstall redis
In my case, it was the password that contained some characters like ', after changing it the server started without problems.
Just like Aaron, in my case brew services list claimed redis was running, but it wasn't. I found the following information in my log file at /usr/local/var/log/redis.log:
4469:C 28 Feb 09:03:56.197 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
4469:C 28 Feb 09:03:56.197 # Redis version=4.0.9, bits=64, commit=00000000, modified=0, pid=4469, just started
4469:C 28 Feb 09:03:56.197 # Configuration loaded
4469:M 28 Feb 09:03:56.198 * Increased maximum number of open files to 10032 (it was originally set to 256).
4469:M 28 Feb 09:03:56.199 # Creating Server TCP listening socket 192.168.161.1:6379: bind: Can't assign requested address
That turns out to be caused by the following configuration:
bind 127.0.0.1 ::1 192.168.161.1
which was necessary to give my VMWare Fusion virtual machine access to the redis server on macOS, the host. However, if the virtual machine wasn't started, this binding failure caused redis not to start up at all. So starting the virtual machine solved the problem.
I was trying to connect my Redis running in wsl2 from vs code running in Windows.
I have listed down what worked for me and the order in which I have performed these actions:
1) sudo ufw allow 6379
2) Update redis.conf to bind 127.0.0.1 ::1 192.168.1.7
3) sudo service redis-server restart
NOTE: This is the first time I have installed Redis on wsl2 and have not run a single command yet.
Let me know if it works for you.
Thanks.
Redis for Mac:
1- brew install redis
2- brew services start redis
3- redis-cli ping
$ brew services start redis
$ brew services stop redis
$ brew services restart redis
Lunch autostart options:
$ ln -sfv /usr/local/opt/redis/*.plist ~/Library/LaunchAgents
# autostart activate
$ launchctl load ~/Library/LaunchAgents/homebrew.mxcl.redis.plist
# autostart deactivate
$ launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.redis.plist
Redis conf default path : /usr/local/etc/redis.conf
In my case, someone had come along and incorrectly edited the redis.conf file to this:
bind 127.0.0.1 ::1
bind 192.168.1.7
when, it really needed to be this (one line):
bind 127.0.0.1 ::1 192.168.1.7
I am using Ubuntu 18.04
I have just enter this command in CMD
sudo systemctl start redis-server
And it is now working. so I thing my redis server was not started that why it showing me the error
Could not connect to Redis at 127.0.0.1:6379: Connection refused.
I have a GPS module connected to a Raspberry Pi via USB.
For some reason I can't seem to get a fix using:
cgps
it doesn't seem to get a fix and terminates.
I've also tried:
sudo killall gpsd
sudo gpsd /dev/ttyUSB0 -F /var/run/gpsd.sock
and then tried cgps again, but that doesn't seem to work either.
I even tried:
sudo nano /etc/default/gpsd
and changed the line:
GPSD_OPTIONS=""
to:
GPSD_OPTIONS="/dev/ttyACM0"
which apparently worked for others around the web, but after a reboot, that didn't work either.
But for some reason when I do:
gpsmon /dev/ttyUSB0
I get a full readout of data; lat, lon, Sats, altitude, ext.
Is there a way to output gpsmon /dev/ttyUSB0 sentences to a text file?
Also, why can't I obtain a fix using cgps or something similar?
gpsd is a beautiful application to simplify gps use, but it can be a little confusing.
If you're using a Rasbian, or some apt based package system it is best to configure it with sudo dpkg-reconfigure gpsd to avoid complications (tyqos), but isn't necessary. We have preferences for, but you may not,
autostart,
-n Don't wait for a client
-G to listen on all addresses,
-b Broken-device-safety mode, and
autofind
The resultant configuration file looks like
# Default settings for gpsd.
# Please do not edit this file directly - use `dpkg-reconfigure gpsd' to
# change the options.
START_DAEMON="true"
GPSD_OPTIONS="-n -G -b"
DEVICES=""
USBAUTO="true"
GPSD_SOCKET="/var/run/gpsd.sock"
The primary stumbling block with this approach while gpsd is running in this fashion is it will grab the gps before you can. Attempts to independently and directly access the device /dev/whatever will fail as busy.
If you wish to go that route, for whatever reason, before doing anything else, make sure gpsd is not running.
sudo killall gpsd
and remove any sockets gpsd might have left behind,
sudo rm /var/run/gpsd.sock
Check the location of your gps by attaching it and tracking where it went with dmesg | tail. It will look something like
[67338.935645] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[67338.935650] usb 1-1.2: Product: USB-Serial Controller
[67338.935653] usb 1-1.2: Manufacturer: Prolific Technology Inc.
[67338.936154] pl2303 1-1.2:1.0: pl2303 converter detected
[67338.937953] usb 1-1.2: pl2303 converter now attached to ttyUSB1
[67339.806917] pl2303 ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
[67339.807306] pl2303 ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
[67340.018016] pps_ldisc: PPS line discipline registered
[67340.018321] pps pps0: new PPS source usbserial1
[67340.018330] pps pps0: source "/dev/ttyUSB1" added
Then you can check for output with sudo cat /dev/ttyUSB1...or whatever, but you could do that with gpsd running. (You can also pump this into a text file sudo cat /dev/ttyUSB1 > gps_dump.txt, or your gpsmon /dev/ttyUSB0 >gps_dump.txt, but there are more elegant solutions.)
The flip side of the confusion is no gps output from the gpsd because it isn't running or configured 'properly'. (either turned off, not started, or pointing to the wrong device). A few application will tell you it's not running, many just sit in silence without any data. I know of none that will tell you gpsd has been manually set to the wrong device.
If you have killed gpsd, or do not have it automagically start, ensure that it is running with sudo /etc/init.d/gpsd restart
Unless you're doing something odd with odd hardware most cases will spit back data with gpsd in these settings, sparing the need for diagnostic settings.
However, bear in mind cgps will timeout if there is no fix. Check your skyview, and Time To First Fix. xgps, on the other hand, is more resilient for failures and provides clues for the absence, or quality of data. If you have an X server, xgps is actually my preferred test for "is it working". If you don't, but have your Pi on a network (xgps 192.168.0.6, or whatever, because the other machine has gpsd-client installed). Another option is to ssh -X user#192.168.0.6 and then execute xgps)
Telneting into gpsd, while interesting, is another tier diagnostic, as are others.
And finally, a shameless plug for a Python client for gpsd (gps3.py) as means to access the data from a gpsd. It still is alpha, but it doesn't import historical cruft.
You may be binding to the wrong serial. You discover the serial for your GPS device by navigating to the folder below without the device plugged in, then refreshing with the device plugged in.
cd /dev/
ls
My device is called "ttyACM0"
Install the requisite packages.
sudo apt-get install gpsd gpsd-clients python-gps
Stop Daemons
sudo systemctl stop gpsd.socket
sudo systemctl disable gpsd.socket
Expose Service to public ports and localhost
vim /lib/systemd/system/gpsd.socket
Change 127.0.0.1 to 0.0.0.0
Stop GPSD services
sudo killall gpsd
Bind service to serial device
sudo gpsd /dev/ttyACM0 -F /var/run/gpsd.sock
Show GPS Data
gpsmon
This video shows step by step how to do what you are looking for.
How to install GPS on RaspberryPi
https://www.youtube.com/watch?v=A1zmhxcUOxw
I am running an Ubuntu 12.04-based box inside of Vagrant using VirtualBox. So far, everything is fine - except for one thing:
Let's assume that the VM is running. Then, the host goes to standby-mode. After waking it up again, the VM is still running, but its internal clock continues where it stopped when the host went down. So this basically means: Put the host to sleep for 15 minutes, wake it up again, then the VM's internal clock is 15 minutes late.
How can I fix this (setting the time manually is not an option for obvious reasons ;-))? Is there a way to run a script inside of a Vagrant VM whenever the host system changes its state?
I've read in the documentation that by default the VirtualBox Guest Additions sync the time with the host every 10 seconds. Apparently this is not happening, but I can not find any place where it is disabled. So any ideas?
PS: The Guest Additions are installed and match the version of VirtualBox being used.
The documentation lacks some details here.
What VirtualBox does every 10 seconds is just slight adjustement (something like 0.005 seconds). Only when the time difference reaches a threshold (20 minutes by default) a "real" resync is done.
You can reduce the thresold (i.e. to 10 seconds) with the following command:
VBoxManage guestproperty set <vm-name> "/VirtualBox/GuestAdd/VBoxService/--timesync-set-threshold" 10000
Summarizing answers of #zilupe and #Slobodan Kovacevic, solution is to add following to Vagrantfile:
config.vm.provider 'virtualbox' do |vb|
vb.customize [ "guestproperty", "set", :id, "/VirtualBox/GuestAdd/VBoxService/--timesync-set-threshold", 1000 ]
end
This will synchronize clocks each time when desync becomes > 1s (1000ms)
I give an other solution to sync time between guest & host without installing Virtualbox guest addition:
install ntp on your guest, and de-comment these lines in /etc/ntp.conf:
disable auth
broadcastclient
Then, restart ntp with service ntp restart
Active broadcast on your host:
For Linux users, edit your /etc/ntp.conf file and configure broadcast (you must adapt IP):
broadcast 192.168.123.255
For Windows users, activate the "Windows Time" service. You can then read this page to configure it to broadcast time
Then, restart time service on host.
For me to get timesync working I had to do this:
vboxmanage setextradata «machine-name» "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" 0
It turns the timesync on. It was, for some reason, off.
I found a solution:
install ntpdate
add "s" permission for ntpdate, this allows non-root users to run ntpdate as root: sudo chmod u+s /usr/sbin/ntpdate
add one line in ~/.bashrc: ntpdate -u ntp.ubuntu.com
After that, each time you login to the linux system, the time will be sync once.
you can install the VirtualBox Guest Additions in the VM to sync the time automatically by VB.