Abort BGSAVE Already in process - database

I started saving redis-db snapshot by calling BGSAVE command in redis-cli.
It has started running but I keep getting these errors in the logs
[30853] 27 Jan 07:18:41.129 # Background saving error
[30853] 27 Jan 07:18:47.043 * 1 changes in 900 seconds. Saving...
[30853] 27 Jan 07:18:47.058 * Background saving started by pid 13204
[13204] 27 Jan 07:18:47.058 # Failed opening .rdb for saving: Permission denied
[30853] 27 Jan 07:18:47.158 # Background saving error
[30853] 27 Jan 07:18:53.070 * 1 changes in 900 seconds. Saving...
[30853] 27 Jan 07:18:53.085 * Background saving started by pid 13207
[13207] 27 Jan 07:18:53.085 # Failed opening .rdb for saving: Permission denied
[30853] 27 Jan 07:18:53.186 # Background saving error
[30853] 27 Jan 07:18:59.098 * 1 changes in 900 seconds. Saving...
[30853] 27 Jan 07:18:59.113 * Background saving started by pid 13210
[13210] 27 Jan 07:18:59.114 # Failed opening .rdb for saving: Permission denied
[30853] 27 Jan 07:18:59.213 # Background saving error
looks like the redis BGSAVE command is running indefinitely. How to stop this.
Also I tried checking for process pid by ps -aux| grep redis command.
13196 pts/11 S+ 0:00 grep --color=auto redis
30853 ? Ssl 1292:57 /usr/bin/redis-server *:6379
There is no process to kill.
EDIT: These are the permissions to redis folder and dump.rdb file
f: /var/lib/redis
drwxr-xr-x root root /
drwxr-xr-x root root var
drwxr-xr-x root root lib
drwxr-xr-x redis redis redis
f: /var/lib/redis/dump.rdb
drwxr-xr-x root root /
drwxr-xr-x root root var
drwxr-xr-x root root lib
drwxr-xr-x redis redis redis
-rw-rw-rw- redis redis dump.rdb
EDIT2: Got the answer. The problem was somehow the config parameters are changed. The dbfilename and dir values are changed.
Set these values to original through CONFIG SET command and now its working fine. Adding in-case somebody has same problem.
But the question is how did they change. Did this happen to anybody else?
Help me
Thanks

You can either try and fix the file permissions error (does the default save location exist and does redis have permission to write to it?) or you can disable saving with:
config set save ""

Related

what is the .stt file used for in TDengine database?

what is the .stt file used for in TDengine database ?
under the dataDir some of the file is called .stt like this :
ssn#TDengine:/var/lib/taos/vnode/vnode14$ cd ..
ssn#TDengine:/var/lib/taos/vnode$ ls -ltR | grep -i stt
-rwxrwxrwx 1 root root 4096 Jan 11 10:19 v18f1736ver22.stt
-rwxrwxrwx 1 root root 4096 Jan 11 10:19 v19f1736ver16.stt
-rwxrwxrwx 1 root root 4096 Jan 10 20:00 v16f1736ver18.stt
-rwxrwxrwx 1 root root 4096 Jan 10 20:01 v17f1736ver27.stt
may I know what is it for ?
a specific description for this file ,what is it used ,does it impact the database performance,etc.
the .sst file is equivalent to the .last file in the TDengine database 2.0
it is used to store the data fragment that smaller than minrows configuration .

Redis server throwing a Background serving error

it is showing like this in redis server after 20 to 30 mins. the first 20 to 30 mins it is working fine only but after that it is throwing this error.so please help me to solve thisyou can see the image in here
[2476] 24 Jun 19:06:21.293 # Background saving error
[2476] 24 Jun 19:06:27.016 * 1 changes in 3600 seconds. Saving...
[2476] 24 Jun 19:06:27.025 * Background saving started by pid 9044
[9044] 24 Jun 19:06:27.147 # Failed opening .rdb for saving: Permission denied
[9044] 24 Jun 19:06:27.148 # rdbSave failed in qfork: Permission denied
[2476] 24 Jun 19:06:27.230 # fork operation complete
[2476] 24 Jun 19:06:27.231 # Background saving error
[2476] 24 Jun 19:06:33.060 * 1 changes in 3600 seconds. Saving...
[2476] 24 Jun 19:06:33.063 * Background saving started by pid 11396
[11396] 24 Jun 19:06:33.192 # Failed opening .rdb for saving: Permission denied
[11396] 24 Jun 19:06:33.193 # rdbSave failed in qfork: Permission denied
[2476] 24 Jun 19:06:33.264 # fork operation complete
[2476] 24 Jun 19:06:33.265 # Background saving error
[2476] 24 Jun 19:06:39.034 * 1 changes in 3600 seconds. Saving...
[2476] 24 Jun 19:06:39.043 * Background saving started by pid 10516
[10516] 24 Jun 19:06:39.183 # Failed opening .rdb for saving: Permission denied
[10516] 24 Jun 19:06:39.185 # rdbSave failed in qfork: Permission denied
[2476] 24 Jun 19:06:39.245 # fork operation complete
[2476] 24 Jun 19:06:39.246 # Background saving error
[2476] 24 Jun 19:06:45.073 * 1 changes in 3600 seconds. Saving...
[2476] 24 Jun 19:06:45.083 * Background saving started by pid 1704
[1704] 24 Jun 19:06:45.219 # Failed opening .rdb for saving: Permission denied
[1704] 24 Jun 19:06:45.221 # rdbSave failed in qfork: Permission denied
[2476] 24 Jun 19:06:45.289 # fork operation complete
[2476] 24 Jun 19:06:45.290 # Background saving error
[2476] 24 Jun 19:06:51.018 * 1 changes in 3600 seconds. Saving...
[2476] 24 Jun 19:06:51.027 * Background saving started by pid 13012
[13012] 24 Jun 19:06:51.150 # Failed opening .rdb for saving: Permission denied
[13012] 24 Jun 19:06:51.152 # rdbSave failed in qfork: Permission denied
[2476] 24 Jun 19:06:51.230 # fork operation complete
[2476] 24 Jun 19:06:51.232 # Background saving error
[2476] 24 Jun 19:06:57.049 * 1 changes in 3600 seconds. Saving...
[2476] 24 Jun 19:06:57.053 * Background saving started by pid 1272
[1272] 24 Jun 19:06:57.177 # Failed opening .rdb for saving: Permission denied
[1272] 24 Jun 19:06:57.178 # rdbSave failed in qfork: Permission denied
[2476] 24 Jun 19:06:57.253 # fork operation complete
[2476] 24 Jun 19:06:57.255 # Background saving error
[2476] 24 Jun 19:07:03.066 * 1 changes in 3600 seconds. Saving...
[2476] 24 Jun 19:07:03.075 * Background saving started by pid 13052
[13052] 24 Jun 19:07:03.208 # Failed opening .rdb for saving: Permission denied
[13052] 24 Jun 19:07:03.210 # rdbSave failed in qfork: Permission denied
[2476] 24 Jun 19:07:03.278 # fork operation complete
This looks like the redis-server process does not have permission to open the .rdb file. Just run redis-server as an administrator on windows, it might solve your problem.

How to implement runas in Linux?

I’ve tried fork, setresgid, setresuid and execvpe — doesn’t work.
Specifically, no errors are returned anywhere, the child process starts OK, I have confirmed all 6 magic numbers returned by getresuid and getresgid match, yet the child process doesn’t have the required permissions.
The files in question are in the /dev/input/ folder. Here’s the permissions:
drwxr-xr-x 3 root root 180 Sep 23 19:47 .
drwxr-xr-x 17 root root 4120 Sep 23 19:47 ..
drwxr-xr-x 2 root root 160 Sep 23 19:47 by-path
crw-rw---- 1 root input 13, 64 Sep 23 19:47 event0
crw-rw---- 1 root input 13, 65 Sep 23 19:47 event1
crw-rw---- 1 root input 13, 66 Sep 23 19:47 event2
crw-rw---- 1 root input 13, 67 Sep 23 19:47 event3
crw-rw---- 1 root input 13, 68 Sep 23 19:47 event4
crw-rw---- 1 root input 13, 69 Sep 23 19:47 event5
The user is a member of the input group, that’s why under normal circumstances it can access these files. However, the process launched with fork/setresgid/setresuid/execvpe can’t access these files.
Here’s relevant lines from the strace log, the log was made with -ff option i.e. only includes a single process:
setresgid(10000, 10000, 10000) = 0
setresuid(10000, 10000, 10000) = 0
execve("/usr/local/bin/dotnet", ["/usr/local/bin/dotnet", "/home/user/launcher/Debug/Desktop.dll"], 0xffffea463f50 /* 1 var */) = 0
.. much later
openat(AT_FDCWD, "/dev/input/event0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 EACCES (Permission denied)
The problem was indeed extra groups. Contrary to my expectation, setresuid does not refresh the list of additional groups.
To set them up, the launcher process first needs to call getgrouplist to query the list of additional groups for the target user, then after the fork call setgroups to apply these values.
The complete sequence of kernel calls to implement a Linux equivalent of CreateProcessAsUser is following:
getgrouplist, fork, chdir, setresgid, setgroups, setresuid, execvpe
Note how setresuid needs to be the very last step before the execvpe. The reason for that, after that call the forked process no longer has permissions to modify these security-related things.
P.S. I wonder how many security bugs in Linux software were caused by the developers forgetting to update that list of extra groups when switching user accounts in their programs?

Choose BSD or sys5 style when creating file in linux

When I create file in linux default group owner becomes gid of process which creates file. If I add SGID to parent directory file will inherit parent directory owner group. Also I can change fs mount options to behave either like sys5 or like BSD.
What if I want to choose this option regardless directory permissions and fs mount options? Is there c function option or syscall parameter which allows you to choose group owner?
$ find . -ls
262 4 drwxrwxr-x 4 devops devops 4096 Apr 24 18:01 .
999 4 drwxrwxr-x 2 devops root 4096 Apr 24 18:03 ./dir1
6093 4 drwxrwsr-x 2 devops root 4096 Apr 24 18:03 ./dir2
$ touch dir1/file dir2/file
$ find . -ls
262 4 drwxrwxr-x 4 devops devops 4096 Apr 24 18:01 .
999 4 drwxrwxr-x 2 devops root 4096 Apr 24 18:04 ./dir1
5576 0 -rw-rw-r-- 1 devops devops 0 Apr 24 18:04 ./dir1/file
6093 4 drwxrwsr-x 2 devops root 4096 Apr 24 18:04 ./dir2
6094 0 -rw-rw-r-- 1 devops root 0 Apr 24 18:04 ./dir2/file
$
And I wish to have something like that:
$ mytouch -s BSD dir1/file1
$ mytouch -s sys5 dir1/file2
$ find dir1 -ls
999 4 drwxrwxr-x 2 devops root 4096 Apr 24 18:10 dir1
6213 0 -rw-rw-r-- 1 devops root 0 Apr 24 18:10 dir1/file1
6214 0 -rw-rw-r-- 1 devops devops 0 Apr 24 18:10 dir1/file2
$
Chances are, you can't.
The implementation of sticky bits exists entirely within the kernel, and there are no options to open() or creat() which control how it operates.
Your program could conceivably call chown() to manually reset the group of the file after creating it. However, this would only work reliably if your process is running as root, or as a member of the group that owns the parent directory.

Failed to open file: Permission denied?

I am running logstash-1.4.1 on Ubuntu and get the following error:
failed to open /home/Desktop/Input/2014-10-02/abc.log: Permission denied - /home/Desktop/Input/2014-10-02/abc.log {:level=>:warn, :file=>"filewatch/tail.rb", :line=>"107"}
Background:
I copied the directory structure of logs from a remote server to my local machine. Now, on running logstash on my local machine on the directory structure I copied, this error occurs.
When I check permissions on the file, it's showing both read write.
Any idea?
As I now checked the logstash console, it's evident that logstash is opening some files and after that permission denied starts coming till end.
CONSOLE:
_open_file: /home/Desktop/Input/2014-10-11/abc.log: opening {:level=>:debug, :file=>"filewatch/tail.rb", :line=>"98"}
/home/Desktop/Input/2014-10-11/abc.log: initial create, no sincedb, **seeking to beginning** of file {:level=>:debug, :file=>"filewatch/tail.rb", :line=>"133"}
_open_file: /home/Desktop/Input/2014-10-21/abc.log: opening {:level=>:debug, :file=>"filewatch/tail.rb", :line=>"98"}
/home/Desktop/Input/2014-10-21/abc.log: initial create, no sincedb, **seeking to beginning** of file {:level=>:debug, :file=>"filewatch/tail.rb", :line=>"133"}
_open_file: /home/Desktop/Input/2014-11-04/abc.log: opening {:level=>:debug, :file=>"filewatch/tail.rb", :line=>"98"}
failed to open /home/Desktop/Input/2014-11-04/abc.log: **Permission denied** - /home/Desktop/Input/2014-11-04/abc.log {:level=>:warn, :file=>"filewatch/tail.rb", :line=>"107"}
_open_file: /home/Desktop/Input/2014-10-10/abc.log: opening {:level=>:debug, :file=>"filewatch/tail.rb", :line=>"98"}
failed to open /home/Desktop/Input/2014-10-10/abc.log: **Permission denied** - /home/Desktop/Input/2014-10-10/abc.log {:level=>:warn, :file=>"filewatch/tail.rb", :line=>"107"}
Is it because of some limit might be there to number of files opened, as logstash is opening files till a limit and after that gives permission denied errors??
My file permissions for files it gives permission denied error:
ls -l ./Input/2014-11-04/abc.log
-rw-rw-r-- 1 userA userA 0 Nov 12 09:56 ./Input/2014-11-04/abc.log
ls -ld ./Input/2014-11-04
drwxrwxr-x 3 userA userA 4096 Nov 12 09:56 ./Input/2014-11-04
ls -l /home/Desktop/Input/2014-10-10/abc.log
-rw-rw-r-- 1 userA userA 0 Nov 12 09:56 /home/userA/Desktop/Input/2014-10-10/abc.log
ls -ld /home/Desktop/Input/2014-10-10
drwxrwxr-x 2 userA userA 4096 Nov 12 09:56 /home/Desktop/Input/2014-10-10
EDIT:
Logstash is run using userA.
Detailed File Permissions:
ls -ld /home/
drwxr-xr-x 3 root root 4096 Aug 27 2013 /home/
ls -ld /home/Desktop/
drwxr-xr-x 7 userA userA 4096 Nov 12 12:45 /home/Desktop/
ls -ld /home/Desktop/Input/
drwxrwxr-x 47 userA userA 4096 Nov 12 10:50 /home/Desktop/Input/
ls -l /home/Desktop/Input/abc.log
-rw-rw-r-- 1 userA userA 0 Nov 12 09:56 /home/Desktop/Input/abc.log

Resources