I am running x2go server on debian testing and connecting to it from another linux machine. Everything works fine but occasionally (approximately after 2-3 days of use over which I connect and disconnect from the client many times), the host machine says the /tmp/... is on a read-only partition, and everything stops working. x2go client does not connect when this happens. I can ssh to the server but nothing works on it. I am unable to even cleanly reboot the machine when that happens. I only need to physically hard-boot the machine.
I don't know if this is happening because of x2go, but it never happened before I started dabbling with x2go.
Is this a known problem? Any ideas about how to debug?
V.
Did you check if /tmp/ is really read-only when that happens? If it is, you need to find out why. I don't know how x2go could make it ro, so there's likey a different reason for it.
Hanno
On Sun, May 01, 2022 at 08:48:41PM +0530, Vikas Rawal wrote:
I am running x2go server on debian testing and connecting to it from another linux machine. Everything works fine but occasionally (approximately after 2-3 days of use over which I connect and disconnect from the client many times), the host machine says the /tmp/... is on a read-only partition, and everything stops working. x2go client does not connect when this happens. I can ssh to the server but nothing works on it. I am unable to even cleanly reboot the machine when that happens. I only need to physically hard-boot the machine.
I don't know if this is happening because of x2go, but it never happened before I started dabbling with x2go.
Is this a known problem? Any ideas about how to debug?
V.
x2go-user mailing list x2go-user@lists.x2go.org https://lists.x2go.org/listinfo/x2go-user
On Sun, 1 May 2022 17:38:49 +0200 Hanno Foest <hurga-x2go@tigress.com> wrote:
Did you check if /tmp/ is really read-only when that happens? If it is, you need to find out why. I don't know how x2go could make it ro, so there's likey a different reason for it.
If /tmp/ is on the root file system and there is some error somewhere, the root fs remounts ro. This is the default in Debian:
$ grep error /etc/fstab /dev/sda3 / ext4 discard,noatime,nodiratime,errors=remount-ro 0 1
It's the "errors=remount-ro" option.
R.
-- richard lucassen https://contact.xaq.nl/
Did you check if /tmp/ is really read-only when that happens? If it is, you need to find out why. I don't know how x2go could make it ro, so there's likey a different reason for it.
/tmp is on root, and does become read-only. So does everything else on the root partition. And thus nothing works.
I somehow suspect that the files x2go creates on /tmp might be causing the errors which make the root remounted as ro. I have not had this problem before I started playing with x2go. I am not sure how to debug this, but I will try when this happens next time and report.
Thanks
Well, x2gocleansessions does indeed create some files on /tmp every two seconds and deletes them again, but creating and deleting files on /tmp is hardly something x2go specific, and it should not cause file system errors either.
Taking a guess, I would say your root partition is on some kind of flash memory, which doesn't like the constant writes, and eventually bugs out. Console messages should have something, or you could use remote syslog if console is not accessible for some reason.
To mitigate the issue, I would suggest using tmpfs for /tmp - RAM does not wear out. But your root media seems to already have issues, which will cause problems sooner or later in a different context.
Hanno
On Mon, May 02, 2022 at 04:34:44AM +0530, Vikas Rawal wrote:
Did you check if /tmp/ is really read-only when that happens? If it is, you need to find out why. I don't know how x2go could make it ro, so there's likey a different reason for it.
/tmp is on root, and does become read-only. So does everything else on the root partition. And thus nothing works.
I somehow suspect that the files x2go creates on /tmp might be causing the errors which make the root remounted as ro. I have not had this problem before I started playing with x2go. I am not sure how to debug this, but I will try when this happens next time and report.
Thanks
Taking a guess, I would say your root partition is on some kind of flash memory, which doesn't like the constant writes, and eventually bugs out. Console messages should have something, or you could use remote syslog if console is not accessible for some reason.
It is on an ssd. So, I guess that might be a problem.
To mitigate the issue, I would suggest using tmpfs for /tmp - RAM does not wear out.
Could one specify where x2go keeps its tmp files? In that case, a separate tmpfs mount for it would solve the problem. Unless keeping all of /tmp on a tmpfs is recommended.
But your root media seems to already have issues, which will cause problems sooner or later in a different context.
Yes, I realise that. I hope running fsck on the root partition will fix that. I will look into it when I am on that system next.
Thanks a lot for all your advice.
V.
On Mon, 2 May 2022 08:44:34 +0530 Vikas Rawal <vikasrawal@gmail.com> wrote:
To mitigate the issue, I would suggest using tmpfs for /tmp - RAM does not wear out.
Could one specify where x2go keeps its tmp files? In that case, a separate tmpfs mount for it would solve the problem. Unless keeping all of /tmp on a tmpfs is recommended.
As said before, x2gocleansessions writes 4 files to /tmp each 2 seconds. What I did is add a TMPDIR variable to the shell init script (I run sysV):
/etc/init.d/x2goserver
mkdir -p -m 700 /tmp/x2go export TMPDIR=/tmp/x2go
The reason I use a subdir on /tmp is that if you write in /tmp the /tmp dir itself is modified (run 'stat /tmp/') and now everything takes place on a ramdisk.
And /tmp/ runs on tmpfs in /etc/fstab: tmpfs /tmp tmpfs defaults 0 0
Maybe you may want to create a wrapper script in case you do not run sysV.
R.
-- richard lucassen https://contact.xaq.nl/
On Mon, May 02, 2022 at 09:20:26AM +0200, richard lucassen wrote:
mkdir -p -m 700 /tmp/x2go export TMPDIR=/tmp/x2go
The reason I use a subdir on /tmp is that if you write in /tmp the /tmp dir itself is modified (run 'stat /tmp/') and now everything takes place on a ramdisk.
In general, that step should not be necessary. The /tmp dir itself is not updated, just the mounted filesystem is. You only see the /tmp dir itself when you unmount the file system again. For example:
[root@ ~]# stat /mnt ... Change: 2022-05-02 14:23:55.000000000 +0200 [root@ ~]# umount /mnt [root@ ~]# stat /mnt ... Change: 2021-01-06 16:44:39.735500911 +0100
- Hanno
On Mon, 2 May 2022 15:23:06 +0200 Hanno Foest <hurga-x2go@tigress.com> wrote:
The reason I use a subdir on /tmp is that if you write in /tmp the /tmp dir itself is modified (run 'stat /tmp/') and now everything takes place on a ramdisk.
In general, that step should not be necessary. The /tmp dir itself is not updated, just the mounted filesystem is. You only see the /tmp dir itself when you unmount the file system again. For example:
[root@ ~]# stat /mnt ... Change: 2022-05-02 14:23:55.000000000 +0200 [root@ ~]# umount /mnt [root@ ~]# stat /mnt ... Change: 2021-01-06 16:44:39.735500911 +0100
Yep, you're right, thnx for pointing this out!
R.
-- richard lucassen https://contact.xaq.nl/
-
Hanno Foest -
richard lucassen -
Vikas Rawal