Beiträge von dsm1212

I tried the refresh and it didn't work but then I saw you posted 7.8.7 and that fixed it!

Thanks again, you keep slimming my system down! I was able to remove the wetty container now. :-).

Yes, when it works, the text/background invert for the selected area.

When I say doesn't work, I mean it doesn't invert the colors of the highlighted area.

The selection highlighting is still not working. As I described above:

If the Open UI comes up in day mode then when I open the Host Shell (or any container shell), highlighting doesn't indicate, the selection works though.

If I started in night mode and then switch to day mode it works.

If I start in day mode (it doesn't work), then switch to night mode (it works), then switch back to day mode (it doesn't work).

Something isn't getting initialized right when starting in day mode.

Yes that fixed it thanks!

The dircolors thing I just set SHELL=/bin/bash in my .bashrc. I'm not sure why through this path SHELL wasn't set but that fix is fine as far as I'm concerned.

I fixed the dircolors error by setting SHELL. It's the pts error I'd like to fix or bug.

And oddly it seems selection highlight on macos with chrome is not working if the cterm starts in day mode.

steve

Ok, so this is totally repeatable. If I last use the cterm to "Host shell" in night mode, then when I select "Open UI" it opens in night mode and selection is good. If I switch to day mode selection is also working. But if I'm in day mode last so that the "Open UI" starts in day mode then when I open "Host Shell" selection is not visible. It is selecting but it's not visually indicated.

When I connect to the "host" in the container list, I get this output:

mesg: cannot open /dev/pts/4: Permission denied

I believe this has to do with logging in as root and then using su to a specified user. I think the answer is that the su should use "su -P", but I'm not sure.

Also, maybe more important :-), when in "day mode" text highlighting doesn't work. So that mesg line above when I tried to copy it shows no selection. In night mode it shows inverted.

steve

I use swag and don't have this issue. You should check your the log/nginx folder to see if the logs will tell you anything. Also check the swag docker log output. Otherwise you will have to look through your config. You must have set up some proxy configs? Maybe one of them is causing the issue. Maybe start fresh, make sure it's ok, and then add in one change at a time.

So my original interface is a bonded link and oddly that page lets me clear the dns field and save so I have a way to remove the dup for now. But it seems odd the simple interface (which has mac address above the dns field) won't let me save dns list blank.

On OMV7 I had an unused nic on my nas for a long time. I wanted to configure it and it was saved with the domain name server blank. The dns server was already in my resolv.conf but to be consistent I put in my router ip for the dns server on the new interface and saved. Since my other nic had the same dns server I had two of the same value in my resolv.conf and it bumped another entry down to four (which shows some warning that only 3 will be used). So I went back into the ui to remove the dns server on this port but the UI won't let me save it blank. It says dns is a required field. On most systems all nic's will have the same dns config so I think we should do one of 1) don't write out dups to resolv.conf, or 2) allow to save the interface with dns blank, 3) move the dns config out of the interface config, or 4) show the same dns config values on every interface page. Maybe this is complicated by the fact that I have ipv4 configured static and ipv6 dynamic.

Zitat von spupuz

Do you have pve kernel and zfs?

I do not have these in use.

I had a flawless upgrade. I had to install the md plugin but the installer told me that. Zero issues so far. I was a little worred about having pihole running under docker, but the installer did everything it needed I guess without shutting that down. After reboot everything just worked.

Nice work to votdev and whomever else contributed!

You can always check the changelog to see if there are updates, but remember omv7 is in progress now so most likely things will slow down on omv6.

Well, those are normally fairly frequent if you look at daemon log. You shouldn't have GB of them though. Maybe grep them to another file so you can tell how much they are really causing.

If your syslog is the standard format then something like this will give you a count of lines by service:

$ awk '{print $5}' syslog | sed s/\[0-9\]//g | sort | uniq -c

294 CRON[]:

1 MR_MONITOR[]:

31 anacron[]:

3 apt-helper[]:

112 containerd[]:

22 cron-apt:

34 dockerd[]:

3 fstrim[]:

85 kernel:

21 omv-sfsnapadm:

5 openmediavault-check_btrfs_errors:

1 openmediavault-check_ssl_cert_expiry:

1 openmediavault-pending_config_changes:

2 rsync-a-feec-c--eae:

2 rsync-bbd-db--b-aecad:

2 rsync-bcca-ca-f-e-ccafaeb:

2 rsync-daca-edd-b-ad-cdca:

2 rsync-efbc-ed-eb-baa-bf:

2 rsync-fcecb-c-ed-b-bfdfada:

1 rsyslogd:

28 smartd[]:

3 systemd-networkd-wait-online[]:

28 systemd-networkd[]:

24 systemd-udevd[]:

272 systemd[]:

1 upsd[]:

On the next rotate .1 gets compressed to .2.gz. But this is the default behavior on all of our systems so I wouldn't dwell on it.

To fix your problem you need to look through the latest log and address whatever is spamming it. Maybe debug level logging is on for some service you have installed. Or there is some pernicious error getting logged.

Because of the other issue I mentioned your journald log files are probably huge too. I would sort the issue and then you can truncate the journal log to a time after it is fixed.

Logrotate doesn't compress the .1 file version until it creates the next one. There is a setting for this you can added to /etc/logrotate.conf. I think it is called delayedCompress. However if you disk is full you won't be able to compress it anyhow.

You already have 2G of syslog so I'd like through the current log and see what is spamming it. My syslog from today is only 54kB :-).

steve

Those files should be covered by logrotate. Can you check if that is running regularly? It normally is called via /etc/cron.daily/logrotate.

Related to this though journald in my install was not limited and would grow to fill the disk. I requested an enhancement for this but it got auto-closed (https://github.com/openmediavault/openmediavault/issues/1457). Journald size is not limited in size with the default install. Add this line after [Journal} in /etc/systemd/journald.conf and restart journald.

SystemMaxUse=10G

That slice is just sort of the big bucket resources are coming out of. You could create a smaller slice for docker and limit it. Then you would just have docker crashing, but it would be better to figure out what is leaking. Just run "docker stats" and watch it. Hopefully it will be obvious.

steve

How is your swap configured? Is it possible the system is starting to swap and swap is either not available or not working? When it comes to memory though its hard to tell who is a victiim and who is the guilty party.

The oom killer has a scoring algorithm to pick a victim and it's picking the process running QtWebEngine. Try shutting down whatever docker container is using the Qt libratry and see if the system gets stable.

Also maybe change the mount -a to mount the exact disk which was problematic. The mount -a is causing docker to remount some things every time you run the command and that might be stressing a little used code path leading to a leak somewhere.

steve