ubuntu 16.04 server. My first ubuntu, so yeah, ubuntu newbie factor.
System time on server is about 17 minutes fast. I can reset it many various ways successfully at the command line. In every case, within 15 or so seconds, it will be reset to the wrong time again. systemd seems to be at the root of it. In message log:
systemd[20113]: Time has been changed
I assumed the culprit was timedatectl. Made sure to disable and check:
root#portal:~# systemctl status systemd-timesyncd.service
â systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; disabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
ââdisable-with-time-daemon.conf
Active: inactive (dead)
Docs: man:systemd-timesyncd.service(8)
root#portal:~# systemctl list-units|grep 'time-sync'
root#portal:~#
This:
root#portal:~# ntpdate -s 0.north-america.pool.ntp.org
root#portal:~# journal -f
Results in this:
Dec 08 20:04:18 portal sudo[4486]: pam_unix(sudo:session): session opened
for user root by owen(uid=0)
Dec 08 19:46:44 portal systemd[2814]: Time has been changed
Dec 08 19:46:44 portal ntpdate[4502]: step time server 171.66.97.126 offset -1098.814353 sec
Dec 08 20:05:35 portal systemd[2814]: Time has been changed
Notice the timestamp of each log entry...
What, pray tell, is resetting the time and where is it getting the ntp server setting, and why is it wrong??? I thought the large drift might be part of the issue, but it doesn;t match up with the number of minutes it's off...
TIA
FTR, this turned out to be the date on the virtual server being wrong. I had checked the hardware server itself and it was accurate, but the date/time via vmware was off a weird increment. Once I corrected this, everything settled down.
Related
I've been working on trying to integrate onlyoffice with my working nextcloud app. I've attempted this many times and in many different ways. I believe I understand "most" of the mistakes I've made previously...but there always seems to be one more.
Nextcloud is running on a Ubuntu 22.04 VM. I have another VM operating nginx reverse proxy for this and the other apps I want to expose to the outside. I've decided on this attempt to also run onlyoffice on the nextcloud server but using different ports from that app.
Using the modified template suggested for SSL enabled nginx, when I attempt to start the service, I get:
bonzo#cloud:/etc/nginx/conf.d$ systemctl status nginx.service
nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Fri 2022-08-05 15:12:02 CDT; 8s ago
Docs: man:nginx(8)
Process: 7990 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=1/FAILURE)
CPU: 26ms
Aug 05 15:12:02 cloud systemd[1]: Starting A high performance web server and a reverse proxy
server...
Aug 05 15:12:02 cloud nginx[7990]: nginx: [emerg] host not found in upstream "docservice" in
/etc/nginx/includes/ds-docservice.conf:74
Aug 05 15:12:02 cloud nginx[7990]: nginx: configuration file /etc/nginx/nginx.conf test failed
Aug 05 15:12:02 cloud systemd[1]: nginx.service: Control process exited, code=exited,
status=1/FAILURE
Aug 05 15:12:02 cloud systemd[1]: nginx.service: Failed with result 'exit-code'.
Aug 05 15:12:02 cloud systemd[1]: Failed to start A high performance web server and a reverse
proxy server.*
When I looked at the line 74 in ds-docservice.conf, it shows this:
location / {
proxy_pass http://docservice;
}
And, I'm not exactly sure what it is expecting to see there. I haven't included it in this first post but I'd be happy to share my ds.conf or any other logs/configs that would be required for help with this. I also realize this is probably going to be something silly that I've missed or messed up, I'm still new to nginx and integrating onlyoffice has been a lot more difficult than you'd think, from the literature and yt vids I've seen!
Thanks for any help
I have a setup of sensu core(single server with muliple clients).
I am facing the issue like - 'No keepalive sent from client for 7807 seconds (>=180)' from multiple clients though they instances are alive.
I've checked the time in both client and server instances. It does not have much variations(only in secs). I tried to install ntpdate on both instances.
[root#client-machine user]# ntpdate pool.ntp.org
31 Aug 14:07:50 ntpdate[14158]: the NTP socket is in use, exiting
[root#server-machine:/home/user]# ntpdate pool.ntp.org
31 Aug 14:08:04 ntpdate[29031]: the NTP socket is in use, exiting
At intermittently, status in uchiwa shows green for this client-machine and it automatically goes to RED for further checks
Kindly advise to get rid of this problem!
I had the same issue. Resolved it by first setting the timezone and then installing the following packages
date
timedatectl set-timezone Europe/Dublin
yum -y install chrony
timedatectl set-ntp true
Digitalocean disabled my droplet's internet access. After fixing the error (rollback to older backup) they restored the internet access. But afterwards I constantly get an error when deploying, I can't seem to get my Postgres database up and running.
I'm getting an error each time I try to deploy my application.
PG::ConnectionBad: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
So I used SSH to login to my server and check if my Postgres was actually running with:
pg_lsclusters
Results into:
Ver Cluster Port Status Owner Data directory Log file
9.5 main 5432 down postgres /var/lib/postgresql/9.5/main /var/log/postgresql/postgresql-9.5-main.log
Postgres server status
So my Postgres server seems to be down. I tried putting it 'up' again with:
pg_ctlcluster 9.5 main start After doing so I got the error: Insecure directory in $ENV{PATH} while running with -T switch at /usr/bin/pg_ctlcluster line 403.
And /usr/bin/pg_ctlcluster on line 403 says:
system 'systemctl', 'is-active', '-q', "postgresql\#$version-$cluster";
But I'm not to sure what the problem could be here and how I could fix this.
Update
I also tried updating the permissions on /bin to 755 as mentioned here. Sadly that did not fix my problem.
Update 2
I changed the /usr/bin to 755. Now when I try pg_ctlcluster 9.5 main start, I get this:
Job for postgresql#9.5-main.service failed because the control process exited with error code. See "systemctl status postgresql#9.5-main.service" and "journalctl -xe" for details.
And inside the systemctl status postgresql#9.5-main.service:
postgresql#9.5-main.service - PostgreSQL Cluster 9.5-main
Loaded: loaded (/lib/systemd/system/postgresql#.service; disabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2018-01-28 17:32:38 EST; 45s ago
Process: 22473 ExecStart=postgresql#%i --skip-systemctl-redirect %i start (code=exited, status=1/FAILURE)
Jan 28 17:32:08 *url* systemd[1]: Starting PostgreSQL Cluster 9.5-main...
Jan 28 17:32:38 *url* postgresql#9.5-main[22473]: The PostgreSQL server failed to start.
Jan 28 17:32:38 *url* systemd[1]: postgresql#9.5-main.service: Control process exited, code=exited status=1
Jan 28 17:32:38 *url* systemd[1]: Failed to start PostgreSQL Cluster 9.5-main.
Jan 28 17:32:38 *url* systemd[1]: postgresql#9.5-main.service: Unit entered failed state.
Jan 28 17:32:38 *url* systemd[1]: postgresql#9.5-main.service: Failed with result 'exit-code'.
Thanks!
You better not mix systemctl and pg_ctlcluster. Let systemctl makes the calls to pg_ctlcluster with the right user and permissions. You should start your postgresql instance with
sudo systemctl start postgresql#9.5-main.service
Also, check the errors in the startup log. You can post them too, to help you figure out what's going on.
Your systemctl status also outputs that the service is disable, so, when the server reboots, you will have to start the service manually. To enable it run:
sudo systemctl enable postgresql#9.5-main.service
I hope it helps
It is mainly because /etc/hosts file is somehow changed.I have removed extra space inside /etc/hosts file.Use cat /etc/hosts
Add these lines into the file
127.0.0.1 localhost
127.0.1.1 your-host-name
::1 ip6-localhost ip6-loopback
And I have given permission 644 to /etc/hosts file.It is working for me even after the reboot of the system.
I've been trying to set up the correct date in my Beaglebone Black but the solutions I've tried are not permanent, everytime I poweroff the Beagle and power on later, the date is wrong again.
So this is what initially looks like:
root#beaglebone:~# date
Sat May 21 17:48:28 CDT 2016
Then I installed ntp and ntpdate
root#beaglebone:~# apt-get install ntp ntpdate
Reading package lists... Done
Building dependency tree
Reading state information... Done
ntp is already the newest version.
ntpdate is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
After that I edit the ntp.conf file like this
# pool.ntp.org maps to about 1000 low-stratum NTP servers. Your server will
# pick a different set every time it starts up. Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
server 0.north-america.pool.ntp.org
server 1.north-america.pool.ntp.org
server 2.north-america.pool.ntp.org
server 3.north-america.pool.ntp.org
...
# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust
restrict 192.168.0.11 mask 255.255.255.0 nomodify notrap
The next step was
root#beaglebone:~# rm /etc/localtime
root#beaglebone:~# ln -s /usr/share/zoneinfo/America/Mexico_City /etc/localtime
After that I was supposed to enable the ntp service with
root#beaglebone:~# systemctl enable ntpdate.service
Failed to enable unit: No such file or directory
or
root#beaglebone:~# service ntpdate start
Failed to start ntpdate.service: Unit ntpdate.service not found.
I couldn't continue with thas because I don't have the ntp.service file so then I tried this
root#beaglebone:~# timedatectl set-ntp true
root#beaglebone:~# timedatectl status
Local time: Sat 2016-05-21 18:16:10 CDT
Universal time: Sat 2016-05-21 23:16:10 UTC
RTC time: Sat 2016-05-21 23:16:11
Time zone: America/Mexico_City (CDT, -0500)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no
root#beaglebone:~# nano /etc/systemd/timesyncd.conf
[Time]
NTP=0.north-america.pool.ntp.org 1.north-america.pool.ntp.org 2.north-america.pool.ntp.org 3.north-america.pool.ntp.org
FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
Finally I reboot and seems to work
root#beaglebone:~# timedatectl status
Local time: Sun 2017-09-10 23:32:28 CDT
Universal time: Mon 2017-09-11 04:32:28 UTC
RTC time: Mon 2017-09-11 04:32:28
Time zone: America/Mexico_City (CDT, -0500)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no
But then again, after poweroff the time sets itself back to May 21st, 2016. I even tried set and sync the clock manually with hwclock --set --date "date" --localtime and systohc but after poweroff the result is the same.
Am I missing something or doing something wrong?
I also change 'UTC' to 'LOCAL' in /etc/adjtime and time goes back to May 2016.
Thanks.
Try this:
dpkg-reconfigure tzdata
This should work. A prompt appears and you can configure it with a graphical interface. It is as easy as America and enter. And then, you can pick your time zone, too.
Seth
I have a MongoDB collection with ~5.5M records. My attempts to index it, whether on a single field or with a compoundIndex fail as the indexing process proceeds normally but then when it reaches 100% where I presume it should stop, it goes past 100% and just continues on. I've left it running for 10 hours but it never ended.
The fields I try to index on are longs or doubles.
I'm running the latest MongoDB version on x64 Windows.
Am I right to think that this is abnormal behaviour? Any ideas what I can do?
Wed Sep 05 10:22:37 [conn1] 415000000/5576219 7442%
Wed Sep 05 10:22:48 [conn1] 417000000/5576219 7478%
Wed Sep 05 10:22:59 [conn1] 419000000/5576219 7514%
Per helpful advice from mongodb-users list:
This was likely due to running out of disk space and getting the database corrupted due to that.
What I did is I cleared up disk space, then ran "mongodump --repair" and then "mongorestore".