root#master:/usr/lib# impala-shell
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
Starting Impala Shell without Kerberos authentication
Then it hangs here. Who know how to diagnose this problem?
Impala related service have been started.
root#master:/usr/lib# ps -ef | grep impala
root 7551 1 0 05:46 ? 00:00:03 /usr/lib/impala/sbin/impalad
impala 11328 1 0 06:44 ? 00:00:00 /usr/lib/impala/sbin/statestored -log_dir=/var/log/impala -state_store_port=24000
impala 11395 1 0 06:45 ? 00:00:03 /usr/lib/impala/sbin/catalogd -log_dir=/var/log/impala
root 11703 1 0 06:55 ? 00:00:00 grep --color=auto impala
/tmp/impalad.ERROR:
Log file created at: 2016/06/14 07:09:31
Running on machine: master
Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg
E0614 07:09:31.558585 11834 logging.cc:120] stderr will be logged to this file.
E0614 07:09:32.755619 11918 thrift-server.cc:176] ThriftServer 'backend' (on port: 22000) exited due to TException: Could not bind: Transport endpoint is not connected
E0614 07:09:32.755651 11834 thrift-server.cc:165] ThriftServer 'backend' (on port: 22000) did not start correctly
E0614 07:09:32.755666 11834 impalad-main.cc:78] ThriftServer 'backend' (on port: 22000) did not start correctly
Related
I got an error when running systemctl start edb-efm-4.5 command in terminal
error
startup-efm.conf file
where my postgres 10 main and replication cluster both are running on localhost 5432 and 5433 port.
and my os is ubuntu 18.04 , and i have used advanced postgresql server 11
here i am attaching pg_hba.conf file screenshot
pg_hba.conf file
here i am attaching efm.properties file screenshot
efm.properties 1
efm.properties 2
efm.properties 3
efm.properties 4
where my expected output is that edb-efm-4.5 cluster runs successfully
Environment
Windows10 home
▼WSL info
//Powershell
> wsl -l -v
NAME STATE VERSION
* Ubuntu-18.04 Running 2
▼.wslconfing setting
set .wslconfig file on C:\Users\ {username}
[wsl2]
memory=8GB
localhostForwarding=true
Problem
▼ at first after running docker in WSL
・
・
・
web_1 | => Booting Puma
web_1 | => Rails 6.0.3 application starting in development
web_1 | => Run `rails server --help` for more startup options
web_1 | [Simple Form] Simple Form is not configured in the application and will use the default values. Use `rails generate simple_form:install` to generate the Simple Form configuration.
web_1 | Puma starting in single mode...
web_1 | * Puma version: 5.1.1 (ruby 2.7.2-p137) ("At Your Service")
web_1 | * Min threads: 5
web_1 | * Max threads: 5
web_1 | * Environment: development
web_1 | * PID: 50
web_1 | * Listening on http://0.0.0.0:3000
web_1 | Use Ctrl-C to stop
・When I try to connect from browser "localhost:3000", timeout error
・Serch "hostname -I" in WSL, and connect from browser of this IP address, connected
▼ after executing server several times
・Can't connect "localhsot", and even IP address which is serched by "hostname -I" as well (timeout error)
Other
When I execute curl http://localhost:3000 in Powershell, I get error
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest]、WebExce
ption
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
The question was some time ago but one workaround currently is to shutdown WSL via
wsl --shutdown
You can then open up your distro and starting your server as usual.
Voilá you should be able to connect now.
If you are using Docker make sure to close it, if it is configured to use the WSL 2 backend. After your distro is up and running again you can launch Docker as usual.
Some issues on GH you could also relate to:
https://github.com/microsoft/WSL/issues?q=is%3Aissue+is%3Aopen+connecting+localhost
EDIT:
make sure you have the latest WSL2 Kernel installed. Some issues are related to older Kernel versions. Current is 5.4.+
to get the Kernel updates automatically:
it is served by windows update if you check "include updates for other microsoft products"
I'm trying to setup a minecraft server for my kid and screen is giving me fits. I've been following this tutorial and I've already consulted this AskUbuntu answer. I'm running on Ubuntu 16.04.5 x64. I have created the following Service file and linked it to /etc/systemd/system/minecraft.service.
[Unit]
Description=Minecraft Server
Documentation=
Wants=network.target
After=network.target
[Service]
User=minecraft
Group=minecraft
Nice=5
EnvironmentFile=-/var/minecraft/unit.conf
KillMode=none
SuccessExitStatus=0 1
ProtectHome=true
ProtectSystem=full
PrivateDevices=true
NoNewPrivileges=true
PrivateTmp=true
InaccessibleDirectories=/root /sys /srv -/opt /media -/lost+found
ReadWriteDirectories=/var/minecraft/server /usr/bin/screen
WorkingDirectory=/var/minecraft/server
#ExecStartPre= /usr/bin/screen -dmS Minecraft
ExecStart= /usr/bin/screen -dm -S Minecraft '/usr/bin/java -Xmx1500M -Xms1024M -jar /var/minecraft/server/craftbukkit-1.13.jar'
ExecStop=/usr/bin/screen -S minecraft -p 0 -X stuff "stop^M"
[Install]
WantedBy=multi-user.target
When I monitor the service startup, I get the following in the journalctl logs:
Aug 05 14:55:41 spigot-1 systemd[1]: Started Minecraft Server.
Aug 05 14:55:41 spigot-1 screen[9869]: No screen session found.
Per the SO post I referenced, I already changed the permissions in /var/run/screen. This is the current setup:
root#spigot-1:/var/minecraft/server# ls -alR /var/run/screen/
/var/run/screen/:
total 0
drwxrwxrwx 4 root root 80 Aug 5 14:12 .
drwxr-xr-x 23 root root 860 Aug 5 14:11 ..
drwx------ 2 minecraft minecraft 40 Aug 5 14:55 S-minecraft
drwx------ 2 root root 40 Aug 5 14:50 S-root
/var/run/screen/S-minecraft:
total 0
drwx------ 2 minecraft minecraft 40 Aug 5 14:55 .
drwxrwxrwx 4 root root 80 Aug 5 14:12 ..
/var/run/screen/S-root:
total 0
drwx------ 2 root root 40 Aug 5 14:50 .
drwxrwxrwx 4 root root 80 Aug 5 14:12 ..
** Debug Notes **
You'll see the commented ExecStartPre command in there... all that happens if I try to start the screen session with that command is I get a second 'No screen session found' error.
I can launch the server from the command line using 'screen -dmS Minecraft [..]' and reattach. I can do this both as root and as the 'minecraft' user.
Any help would be greatly appreciated
I don't have Ubuntu to hand, but I tried something similar on Fedora 24 and had a similar error. To investigate I added an strace to the screen command and removed PrivateTmp so that I could get the trace output.
ExecStart=/bin/strace -o /tmp/s -f screen -dm -S me bash -c 'sleep 999'
In the output I found that at the end, screen was trying to open a pseudo-tty and failed to do so:
open("/dev/ptmx", O_RDWR) = -1 EACCES (Permission denied)
...
write(1, "No more PTYs.\r\nSorry, could not "..., 52) = 52
I added some ls -l /dev commands to the Unit to see what the effect of the PrivateDevices=true option had been. There was indeed a /dev/ptmx file, but unlike my real /dev it was a symbolic link to /dev/pts/ptmx, instead of just being the special character device. For some reason on my system I have:
$ ls -l /dev/ptmx /dev/pts/ptmx
crw-rw-rw- 1 root tty 5, 2 Aug 6 14:29 /dev/ptmx
c--------- 1 root root 5, 2 Jun 27 08:29 /dev/pts/ptmx
(This is probably a bug depending on the version of systemd and udev.)
So when /dev/ptmx is replaced in the private namespace by a symbolic link to /dev/pts/ptmx, you can no longer open a new pty. A simple fix for testing was sudo chmod a+rw /dev/pts/ptmx which indeed made the Unit work and start the screen process.
This may not be the case for you, but you could undertake a similar debug method to try to find the problem.
I am trying to setup GitLab, Redis and PostgreSQL containers in Kubernetes using Gluster for persistence. GlusterFS nodes are setup on machines (CentOS) external to Kubernetes cluster (running on RancherOS host). Issue is that when GitLab tries starting up, the login page doesn't load. It's a fresh setup and not something that stopped working now.
root#gitlab-2797053212-ph4j8:/var/log/gitlab/gitlab# tail -50 sidekiq.log
...
...
2017-09-07T11:53:03.098Z 547 TID-1fdjck ERROR: /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/sidekiq-5.0.0/lib/sidekiq/processor.rb:84:in `process_one'
2017-09-07T11:53:03.098Z 547 TID-1fdjck ERROR: /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/sidekiq-5.0.0/lib/sidekiq/processor.rb:73:in `run'
2017-09-07T11:53:03.098Z 547 TID-1fdjck ERROR: /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/sidekiq-5.0.0/lib/sidekiq/util.rb:17:in `watchdog'
2017-09-07T11:53:03.098Z 547 TID-1fdjck ERROR: /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/sidekiq-5.0.0/lib/sidekiq/util.rb:26:in `block in safe_thread'
2017-09-07T11:53:03.099Z 547 TID-1fdf1k ERROR: Error fetching job: ERR Error running script (call to f_7b91ed9f4cba40689cea7172d1fd3e08b2efd8c9): #user_script:7: #user_script: 7: -MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled. Please check Redis logs for details about the error.
2017-09-07T11:53:03.100Z 547 TID-1fdf1k ERROR: /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/redis-3.3.3/lib/redis/client.rb:121:in `call'
2017-09-07T11:53:03.100Z 547 TID-1fdf1k ERROR: /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/peek-redis-1.2.0/lib/peek/views/redis.rb:9:in `call'
2017-09-07T11:53:03.100Z 547 TID-1fdf1k ERROR: /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/redis-3.3.3/lib/redis.rb:2399:in `block in _eval'
2017-09-07T11:53:03.100Z 547 TID-1fdf1k ERROR: /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/redis-3.3.3/lib/redis.rb:58:in `block in synchronize'
2017-09-07T11:53:03.100Z 547 TID-1fdf1k ERROR: /usr/lib/ruby/2.3.0/monitor.rb:214:in `mon_synchronize'
2017-09-07T11:53:03.100Z 547 TID-1fdf1k ERROR: /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/redis-3.3.3/lib/redis.rb:58:in `synchronize'
...
So i checked for Redis container logs.
[root#node-a ~]# docker logs -f 67d44f585705
...
...
[1] 07 Sep 14:43:48.140 # Background saving error
[1] 07 Sep 14:43:54.048 * 1 changes in 900 seconds. Saving...
[1] 07 Sep 14:43:54.048 * Background saving started by pid 2437
[2437] 07 Sep 14:43:54.053 # Failed opening .rdb for saving: Permission denied
...
Checked online for this issue and then noticed the following permissions and owner details inside of Redis pod:
[root#node-a ~]# docker exec -it 67d44f585705 bash
groups: cannot find name for group ID 2000
root#redis-2138096053-0mlx4:/# ls -ld /var/lib/redis/
drwxr-sr-x 12 1000 1000 8192 Sep 7 11:51 /var/lib/redis/
root#redis-2138096053-0mlx4:/#
root#redis-2138096053-0mlx4:/# ls -l /var/lib/redis/
total 22
drwxr-sr-x 2 1000 1000 6 Sep 6 10:37 backups
drwxr-sr-x 2 1000 1000 6 Sep 6 10:37 builds
drwxr-sr-x 2 redis redis 6 Sep 6 10:14 data
-rw-r--r-- 1 redis redis 13050 Sep 7 11:51 dump.rdb
-rwxr-xr-x 1 redis redis 21 Sep 5 11:00 index.html
drwxrws--- 2 1000 1000 6 Sep 6 10:37 repositories
drwxr-sr-x 5 1000 1000 55 Sep 6 10:37 shared
drwxr-sr-x 2 root root 8192 Sep 6 10:37 ssh
drwxr-sr-x 3 redis redis 70 Sep 7 10:20 tmp
drwx--S--- 2 1000 1000 6 Sep 6 10:37 uploads
root#redis-2138096053-0mlx4:/#
root#redis-2138096053-0mlx4:/# grep 1000 /etc/passwd
root#redis-2138096053-0mlx4:/#
Ran following and all looked fine.
root#redis-2138096053-0mlx4:/# chown redis:redis -R /var/lib/redis/
However, when i deleted and ran the GitLab deployment YAML again, the permissions inside the Redis container again got skewed up. I am not sure whether Gluster is messing up with the Redis file/folders permissions. Can't think of any other reason right now.
One thing i would like to highlight is that all the three containers are using the same PVC
- name: gluster-vol1
persistentVolumeClaim:
claimName: gluster-dyn-pvc
Above is common for all three. What differs is shown below:
a) postgresql-deployment.yaml
volumeMounts:
- name: gluster-vol1
mountPath: /var/lib/postgresql
b) redisio-deployment.yaml
volumeMounts:
- name: gluster-vol1
mountPath: /var/lib/redis
c) gitlab-deployment.yaml
volumeMounts:
- name: gluster-vol1
mountPath: /home/git/data
Any suggestion?
With the following steps, i was able to resolve the 'Permission denied' issue for Redis:
Created separate volumes for PostegreSQL, Redis and GitLab in GlusterFS.
Created separate Storage Class for all three.
Created PersistentVolumeClaim (PVC) for them and mapped /var/lib/postgresql, /var/lib/redis and /home/git/data to their respective PVCs.
Earlier, all three paths mentioned above were pointing to the same volume in GlusterFS. Somehow, it seems, they were causing issue for Redis.
Monit can not start redis-server properly.
Running Redis through init.d works correctly:
$ sudo su
$ /etc/init.d/redis_6379 start
$ #=> Starting Redis server...
$ ps aux | grep redis
$ #=> root 8980 0.0 0.0 42128 1964 ? Ssl 04:56 0:00 /etc/redis/src/redis-server *:6379
$ /etc/init.d/redis_6379 stop
$ #=> Stopping ...
$ #=> Redis stopped
$ #=> (ps aux| grep redis) There's no redis process.
Running Redis through Monit does not work correctly:
(I killed the Redis process and rm /var/run/redis_6379.pid)
$ sudo su
$ monit start redis
$ ps aux | grep redis
$ #=> root 9082 0.0 0.0 35076 1972 ? Ssl 05:08 0:00 /etc/redis/src/redis-server *:6379
monit.log:
[MSK Jan 6 05:08:14] info : 'redis' start on user request
[MSK Jan 6 05:08:14] info : monit daemon at 3947 awakened
[MSK Jan 6 05:08:14] info : Awakened by User defined signal 1
[MSK Jan 6 05:08:14] info : 'redis' start: /etc/init.d/redis_6379
[MSK Jan 6 05:08:44] error : 'redis' failed to start
[MSK Jan 6 05:08:44] info : 'redis' start action done
Stopping Redis through Monit does not works correclty also:
$ ps aux | grep redis
$ #=> root 9018 0.0 0.0 35076 1968 ? Ssl 05:02 0:00 /etc/redis/src/redis-server *:6379
$ monit stop redis
$ ps aux | grep redis
$ #=> root 9082 0.0 0.0 35076 1972 ? Ssl 05:08 0:00 /etc/redis/src/redis-server *:6379
monit.log
[MSK Jan 6 05:10:02] info : 'redis' stop on user request
[MSK Jan 6 05:10:02] info : monit daemon at 3947 awakened
[MSK Jan 6 05:10:02] info : Awakened by User defined signal 1
[MSK Jan 6 05:10:02] info : 'redis' stop action done
I have:
Ubuntu 12.04.3 LTS
redis-2.8.2
monit-5.3.2
redis instalation path /etc/redis
monit instalation path /etc/monit (installed from apt-get repo)
And following config files:
https://gist.github.com/itsNikolay/665112df34d2eae09330
I had the same problem, and there is no mutch talk about this situation around. I fixed it with another solution, it may concern someone else so I post it here.
in monit configuration file I had
start program = "/etc/init.d/redis start"
stop program = "/etc/init.d/redis stop"
Replacing by the following fixed the problem (with Ubuntu)
start program = "/usr/sbin/service redis start"
stop program = "/usr/sbin/service redis stop"
Just changes owner of /etc/redis dir
$ chown -R root /etc/redis
and restart monit
$ monit restart
The problem is gone. Strange. I wish it helps.