Qubes Manager issues

[Drew White]

Hi folks,

I've just had Qubes Manager go haywire on me.
Freezes  up because it's using 597 MB RAM with 38 MB shared.
That's just rhediculous.

I had to kill the process to get out of it.
And as usual, it won't start again and I have to reboot the system.

I don't see how it could be nearly 600 MB RAM just for one application like that.

Just thought I should let you know the issue.
If it used less RAM, then Dom0 would not require more than 1 GB RAM.
But one would give it 2GB just to be on the safe side.

If anyone else is having this issue, or knows how to resolve this bug, please let me know.
I've complained about Qubes Manager not starting before, but got no resolution then, so
now I'm putting it here where it's the issue, not something else that caused it, because it's
not something else that caused it to be almost 600 MB in RAM.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Qubes Manager leaks memory, which is a known issue:

https://github.com/QubesOS/qubes-issues/issues/860

The current workaround is to restart it occasionally.

Now, if you cannot restart Qubes Manager, then that workaround
obviously will not work for you. However, in order to create an issue
for Qubes Manager not restarting, we need more information. Does it
happen all the time for you, or just sometimes? What are the steps (if
any) to reproduce?

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXdKUiAAoJENtN07w5UDAwDhUQAMoLxmjALhhe7iZq1BW2yoIZ
ID0U0M3w/4mPdCvFjAKucwt/ieYGwXdwUpvxn+pUhhjUJl1RcTOBkD3pZsM3GIdl
F0In4iyRwDTcXAisl8U6TeVHwYNQmQUaGfzoxHYkHGYb3gC3ewdpepMp7kMwRDx9
nbH/JAf5bl1fuJz3jAriOvj3GJHrDAP+TSzc86L8Shb/G72dHkY95PGToVCsal/L
bRxVNkdLYgZRQ7da25HxISOaNqQwk/e4vDc9j/9fELmEnb9raRVQh2D5Vfy0rPgK
GcxRZQc5kWkA2kxMk4tG/+FMeUfMnyVk/4s4tjIk9sJCQ7Z4R99B559Kols0wXSv
evWsoaITjyuTICosMaz18kOLmSPZPImz2tTEssmOabxkVuX2jY8YuJYhzK5aZP0D
WpR8zXbqy6gfaIGF3DD/J/cez/UKdpLfrqGxh/k1sG3GbCx2YHYmtZ7AvKxo++Ej
A/eIUm6UHHVMOAc3K0xY7750AMRXtNeDoQZvkqDnoiogaEtsRT3RWLxr2CXZ8Pq2
BjjBichDxi4/40l4I9Ra43teJHfbPq6WseVjDaFaazBAU6ucZQbItKaIHhrsed7W
rsj/C0sd3Hr7BrPoi3MVdSiDBBuBSAh8CkRGNEbFIEZ+g+X5MGeEg6PJcSHH7+Nb
Ze920SS8Ne1kAUzaVIRx
=tBT/
-----END PGP SIGNATURE-----

[Drew White]

On Thursday, 30 June 2016 14:50:50 UTC+10, Andrew David Wong wrote:

Qubes Manager leaks memory, which is a known issue:

https://github.com/QubesOS/qubes-issues/issues/860

Fair enough, thought it would be something like that.

I just hope it can be fixed soon, especially since it uses 50 MB RAM
and also 40 MB Shared RAM when it initially starts, that's crazy!

I don't see how you can get that much used just by starting it.

 

The current workaround is to restart it occasionally.

 

Now, if you cannot restart Qubes Manager, then that workaround
obviously will not work for you. However, in order to create an issue
for Qubes Manager not restarting, we need more information. Does it
happen all the time for you, or just sometimes? What are the steps (if
any) to reproduce?

Well, it just happens every now and again.

It's running, and it happens.

It was only this time that I thought to look at how much RAM it was using.

Problem is, EVERY TIME that I close it, even just after boot, it will
not start again UNLESS I run it from the CLI and then that allows it to show
the usual errors that I have reported in version 2 of Qubes, which still remain
to be fixed.

I just want to get these issues worked out for those that are going to use
the current Qubes Manager for the rest of the life of Qubes, or else another
one developed by Qubes developers for Qubes.

Once it's fixed, it means I won't see the typical errors occur any more.











 

[Drew White]

Another issue I can see...

When I started the backup, it replicated itself to use ANOTHER X amount of RAM, and then add on the backup processing...

This is really confusing from a programming perspective.

I can understand the fork, but to fork like that is just... not good...
If I had it running at 200 MB RAM, and tried backing up, and it consumed
another 200 MB RAM....

It puts the parent process to sleep even, and just replicates..
I can understand it in regards to the backup, to consume more RAM and then when it's done it destroys itself and frees up that RAM, but when it's only using an extra 1 MB of RAM, and an extra 20 MB shared RAM from the parent process, it isn't really needed.

The backup just finished, the Backup VM window is still open, the child process has become the parent. And is now using more RAM that it was before it started, and the Shared RAM is also higher, because the child became the only remaining entity, since it has killed off the old parent.

Thus, I think the way it is is back to front.

The child should die after notifying the parent of completion, not the other way around.

So currently BEFORE the backup, it was using (approximately) 79 Mb, but AFTER the backup, it's using (approximately) 84 Mb. Because the child process became the parent.

[Chris Laprise]

> --

Drew,

About how long had it been running when you saw it at 597 MB?

Chris

[ni...@kobschaetzki.net]

I have the problem that the Manager "vanishes" when I switch sessions (i.e. from KDE to i3) and I cannot start it or recently I tried to close and reopen it and it wouldn't reopen.

A ps aux in dom0 showed that the process was still running, so killing it let me restart the Manager.

Niels

[Drew White]

On Thursday, 30 June 2016 20:57:22 UTC+10, Chris Laprise wrote:

About how long had it been running when you saw it at 597 MB?

Hi chris,

Well, not very long at all.

Maybe 48 hours.

Normally I don't turn my machine off ever, and I never normally have to reboot

it unless I'm making a huge change, that's the power of linux.

I know I'll have my manager finished shortly, since I saw what was happening

and was told about the memory leak, I figured I'd make a replacement tonight,

just a temporary one until the current manager is fixed.

At the moment, my temporary one does only 70% of the things. But sits at

 7 MB RAM and 21 MB shared RAM. and I've had it running on the laptop here,

normally after running a backup OR restore of a guest, the qubes-manager

is at 59 MB RAM and 29+ Shared RAM. So there is definitely a leak somewhere

in the coding, and I believe it's in the scripting.

There are still all the image errors too. every time a form loads or displays

or the image is loaded or displayed, it has the error.

In Fedora I'm getting Gs-WARNING **: ... errors, so I need to go investigate

that now. Guess I won't have the temporary replacement finished tonight after

all.. What a shame...

Anywho... Niels,

You switch sessions, do you stop the manager and exit it before you switch?

Or do you log out and then back in to a different WM?

When you are in i3 WM can you do CTRL+ESC / System Activity, and see if it's running?

If it is, right click and "Show Application Window". See if it appears.

[Drew White]

I have the problem that the Manager "vanishes" when I switch sessions (i.e. from KDE to i3) and I cannot start it or recently I tried to close and reopen it and it wouldn't reopen.

A ps aux in dom0 showed that the process was still running, so killing it let me restart the Manager.

Yes, I know you said that the "ps aux" said it was running, I'm just asking in the way I asked to find out if it was doable in your position when it is actually running but changing WM to see if it can be brought to the current screen or not, and thus used because it's running.

Because mine, when I kill it, I then can't start it unless I run it from command line.

[ni...@kobschaetzki.net]

I start all my programs via krunner or dmenu, so it is probably the same as when starting them via the command line.

Niels