Unable to move /usr/local/directadmin/data/sessions

Richard G

Verified User
Joined
Jul 6, 2008
Messages
12,563
Location
Maastricht
2017:03:12-22:28:56: Unable to move /usr/local/directadmin/data/sessions/da_sess_HoX6CJxACaeNmRtpD7pfMklgSvcKDOvTBQZNhUYt4AHoZ8xxxxxxxxxxxxxxx.temp to /usr/local/directadmin/data/sessions/da_sess_HoX6CJxACaeNmRtpD7pfMklgSvcKDOvTBQZNhUYt4AHoZ8xxxxxxxxxxxxxxx : No such file or directory
2017:03:12-22:28:56: Unable to move /usr/local/directadmin/data/sessions/da_sess_HoX6CJxACaeNmRtpD7pfMklgSvcKDOvTBQZNhUYt4AHoZ8xxxxxxxxxxxxxxx.temp to /usr/local/directadmin/data/sessions/da_sess_HoX6CJxACaeNmRtpD7pfMklgSvcKDOvTBQZNhUYt4AHoZ8xxxxxxxxxxxxxxx : No such file or directory
2017:03:12-22:28:56: Unable to move /usr/local/directadmin/data/sessions/da_sess_HoX6CJxACaeNmRtpD7pfMklgSvcKDOvTBQZNhUYt4AHoZ8xxxxxxxxxxxxxxx.temp to /usr/local/directadmin/data/sessions/da_sess_HoX6CJxACaeNmRtpD7pfMklgSvcKDOvTBQZNhUYt4AHoZ8xxxxxxxxxxxxxxx : No such file or directory
2017:03:12-22:28:56: Unable to write session file: Unable to move /usr/local/directadmin/data/sessions/da_sess_HoX6CJxACaeNmRtpD7pfMklgSvcKDOvTBQZNhUYt4AHoZ8xxxxxxxxxxxxxxx.temp to /usr/local/directadmin/data/sessions/da_sess_HoX6CJxACaeNmRtpD7pfMklgSvcKDOvTBQZNhUYt4AHoZ8xxxxxxxxxxxxxxx : Success<br>
. Make sure the disk isn't full.

I've got a lot of these lines (I masked the da_sess names with xxxxx at the end) on one of our servers in /var/log/directadmin/error.log.
On the forum I found a couple of similar threads, which stated that only this could be full, like it says here "make sure the disk isn't full". But the disk is not full.

This is a df -h output:
Code:
[root@server18: /]# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/md2       1008G   21G  937G   3% /
tmpfs           7.7G   28K  7.7G   1% /dev/shm
/dev/md1        496M  130M  341M  28% /boot
/dev/md3        1.7T  260G  1.4T  16% /home
/var/tmpMnt     4.6G   23M  4.4G   1% /tmp

As you can see it's a Raid 1 system and / is only 3% used, most full is /boot with 28% and /home with 16%. So hardly near a full disk.

I also found 2 of these.... which I can't explain why this occurs:
Code:
2017:03:12-22:26:55: unable to open /usr/local/directadmin/conf/my.cnf for writing: Permission denied
2017:03:12-22:27:28: unable to open /usr/local/directadmin/conf/my.cnf for writing: Permission denied
I mean I know that they are read-only, I just don't know why something is trying to write to it.

How can these issues be fixed?
 
Last edited:
I'm not sure about reasons of the first issue (probably John could give us insights on this), but the second one might be explained this way:

DirectAdmin does create a secondary my.cnf, but it's only used for the mysqldump calls. It's found at /usr/local/directadmin/conf/my.cnf and should not be changed as it's overwritten regularly (based on the mysql.conf in the same directory).

https://help.directadmin.com/item.php?id=329

So it seems to be Directadmin processes (I won't say for sure which one exactly) that tries to write into the file.
 
Thank you Alex.
However, then this part confuses me:
as it's overwritten regularly (based on the mysql.conf in the same directory)
How can something be overwritten when it's read-only?
-r-------- 1 diradmin diradmin 41 2014-05-18 00:25 my.cnf
and it's like that on all servers.

I hope John can give some more insight in the first issue, because that one does not exist on our other servers.
 
Well 400 permissions do not protect it from removing... actually:

Code:
[root@server ~]# cd /tmp
[root@server tmp]# touch test
[root@server tmp]# chmod 400 test
[root@server tmp]# rm test -v
rm: remove regular empty file `test'? y
removed `test'
[root@server tmp]#

The same directadmin might do...

Code:
# stat /usr/local/directadmin/conf/my.cnf
  File: `/usr/local/directadmin/conf/my.cnf'
  Size: 49              Blocks: 8          IO Block: 4096   regular file
Device: fc07h/64519d    Inode: 2252903     Links: 1
Access: (0600/-rw-------)  Uid: (  496/diradmin)   Gid: (  496/diradmin)
Access: 2017-03-16 05:30:01.000000000 +0700
Modify: 2017-03-16 05:26:00.000000000 +0700
Change: 2017-03-16 05:26:00.000000000 +0700

Server time: Thu Mar 16 18:24:21 +07 2017
 
Last edited:
If dirading is doing it that way, it's possible to change it indeed.
But it still does not explain which DA process is causing the permission denied notices and what is causing the other issue.

As said I don't have these errors on any of the other servers, neither the permission denied error.
So I'm still curious. but thank you for explaining, I did not think of removing first when using the word "overwrite". :)
 
Going further with guessing... I might assume that Directadmin backup process is that... and it first tries to overwrite the file and logs an error that you see.

What are the permissions on the file on other servers?

I've got 600:

Code:
# ls -la /usr/local/directadmin/conf/my.cnf
-rw------- 1 diradmin diradmin 49 Mar 16 05:26 /usr/local/directadmin/conf/my.cnf

and

Code:
# stat /usr/local/directadmin/conf/my.cnf
  File: `/usr/local/directadmin/conf/my.cnf'
  Size: 49              Blocks: 8          IO Block: 4096   regular file
Device: fc07h/64519d    Inode: 2252903     Links: 1
Access: (0600/-rw-------)  Uid: (  496/diradmin)   Gid: (  496/diradmin)
Access: 2017-03-16 05:30:01.000000000 +0700
Modify: 2017-03-16 05:26:00.000000000 +0700
Change: 2017-03-16 05:26:00.000000000 +0700
 
and

Code:
ls -ld  [COLOR=#333333][I]/usr/local/directadmin/data/sessions/
?[/I][/COLOR]
 
It could be backup, but I would like to know for sure and why it's not on the other serves. I'll check that again.

The permissions on those files on the other servers on the my.cnf:
This server 400
2nd server it's 600
3rd server (newest) is also 400.

However I don't have any permission denied notices on the 3rd servers errortaskq.log files. But from server 1 and 2 automated backups are made, which is not the case from server 3, so maybe it has to do with that, and maybe that's why I don't have the error on server 3.
If I undersand you correctly the permissions should be 600? Then I'm prepared to change it.

Server 1:
Code:
# stat /usr/local/directadmin/conf/my.cnf
  File: `/usr/local/directadmin/conf/my.cnf'
  Size: 41              Blocks: 8          IO Block: 4096   regular file
Device: 902h/2306d      Inode: 7996846     Links: 1
Access: (0400/-r--------)  Uid: (  497/diradmin)   Gid: (  497/diradmin)
Access: 2017-03-14 23:21:39.795290226 +0100
Modify: 2014-05-18 00:25:36.419566621 +0200
Change: 2017-03-12 03:32:12.548649213 +0100

Server 2:
Code:
# stat /usr/local/directadmin/conf/my.cnf
  File: `/usr/local/directadmin/conf/my.cnf'
  Size: 41              Blocks: 8          IO Block: 4096   regular file
Device: 902h/2306d      Inode: 31329723    Links: 1
Access: (0400/-r--------)  Uid: (  497/diradmin)   Gid: (  497/diradmin)
Access: 2017-03-12 03:42:16.272612724 +0100
Modify: 2014-01-08 03:04:01.008267111 +0100
Change: 2017-03-12 03:42:12.417612728 +0100

Server 3:
Code:
# stat /usr/local/directadmin/conf/my.cnf
  File: `/usr/local/directadmin/conf/my.cnf'
  Size: 43              Blocks: 8          IO Block: 4096   regular file
Device: 902h/2306d      Inode: 25566423    Links: 1
Access: (0600/-rw-------)  Uid: (  497/diradmin)   Gid: (  497/diradmin)
Access: 2017-03-12 03:17:05.719646593 +0100
Modify: 2017-03-08 20:09:01.754308641 +0100
Change: 2017-03-12 03:17:05.213646592 +0100

Heej that's odd.. Look at that... Modify date on server 3 is different, so it's changed this month, both others are from server installation at 2014. Server 3 was installed in 2016 if I'm not mistaken or at least in 2015.

This is the output of what you asked:
drwx------ 2 diradmin diradmin 4.0K Mar 15 18:13 /usr/local/directadmin/data/sessions/
this is the same on all 3 servers.
 
It could be backup, but I would like to know for sure and why it's not on the other serves. I'll check that again.

You've got two options:

1. run backups in console with debug output
2. or ask John.

;)
 
1.) I don't know how to do that exactly. The backups I make are from server 1 and server 2 to my NAS systems, so I presume ncftpput and I could use the -d (debug) output option. The backups do function properly though.

2.) Yes I will do that, seems better to me.

Thanks for your help and insights!
 
Hi Guys,

1) The my.cnf should be 600, so set it to 600 so that DA can write to it.

2) The session move errors, less sure. I'd guess either permission.. or could be a failing disk (but you'd be seeing errors in many other places too)
But try:
Code:
cd /usr/local/directadmin/data
chown -R diradmin:diradmin sessions
and see what that does for you.

Else I've have to login to check, so create a ticket if the above doesn't help.

John
 
Hello John.

1.) Changed the my.cnf too chmod 600.

2.) It already had diradmin:diradmin as owner, same on all 3 servers. After I checked logs again, it seemed to have happened on all 3 servers, but not always, which is why I did not see it on the other servers at first.
But when checking multiplelogs, Ive seen it happening on all 3 servers at different times.

Servers are always updated together so that's odd. I will create a ticket.
 
I've got a lot of these lines (I masked the da_sess names with xxxxx at the end) on one of our servers in /var/log/directadmin/error.log.
On the forum I found a couple of similar threads, which stated that only this could be full, like it says here "make sure the disk isn't full". But the disk is not full.

hello, I've the same on a Centos7 server, did you fix it?

Code:
# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/md4        9.5G  2.6G  6.5G  29% /
devtmpfs         16G     0   16G   0% /dev
tmpfs            16G     0   16G   0% /dev/shm
tmpfs            16G  881M   15G   6% /run
tmpfs            16G     0   16G   0% /sys/fs/cgroup
/dev/md8         48G  7.8G   38G  18% /usr
/dev/md3        968M   16M  886M   2% /tmp
/dev/md2        238M  139M   83M  63% /boot
/dev/md5        1.6T  350G  1.2T  24% /home
/dev/md6        203G   11G  182G   6% /var
tmpfs           3.2G     0  3.2G   0% /run/user/0
 
Hello.
No I didn't fix it, no need for it. Somewhere, I don't remember if it was on the forums or in a ticket, I was told when the disk was not full I did not need to worry and could ignore the errors, so I did.
Never had any issues.
 
Back
Top