Re: 1Gbps Ethernet drops to 100Mbps
On 5/13/20 1:58 PM, Nazar Zhuk wrote: I have a 1Gbps network port that correctly connects as 1Gbps full duplex on boot, then drops to 100Mbps 4 seconds later. Forcing 1Gbps full duplex with ethtool works fine. Tested to make sure the actual speed is over 100Mbps. I am trying to determine what causes the drop to 100Mbps and how to avoid it. Thanks for the hardware suggestions. It's not that. For whatever reason NetworkManager was configured to force 100Mbps. It's a new install and I don't remember doing that, but that's what it was. -- Nazar
1Gbps Ethernet drops to 100Mbps
Hi all, I have a 1Gbps network port that correctly connects as 1Gbps full duplex on boot, then drops to 100Mbps 4 seconds later. Forcing 1Gbps full duplex with ethtool works fine. Tested to make sure the actual speed is over 100Mbps. I am trying to determine what causes the drop to 100Mbps and how to avoid it. The network port is on a Thunderbolt 3 hub in case this matters. Though it appears that it looks just like a regular 1Gbps card to igb driver. Tried two different Cat6 cables at 5 ft distance to the switch. There is nothing aside from loopback in /etc/network/interfaces and /etc/network/interfaces.d. Relevant log entries: # dmesg | grep -E '(igb|eth|enp9s0)' [1.707669] wmi_bus wmi_bus-PNP0C14:01: WQBC data block query control method not found [5.578360] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k [5.578360] igb: Copyright (c) 2007-2014 Intel Corporation. [6.351902] igb :09:00.0: added PHC on eth0 [6.351903] igb :09:00.0: Intel(R) Gigabit Ethernet Network Connection [6.351904] igb :09:00.0: eth0: (PCIe:2.5Gb/s:Width x1) 64:4b:f0:10:5e:80 [6.352004] igb :09:00.0: eth0: PBA No: 000300-000 [6.352005] igb :09:00.0: Using MSI-X interrupts. 4 rx queue(s), 4 tx queue(s) [6.352464] igb :09:00.0 enp9s0: renamed from eth0 [ 71.234244] IPv6: ADDRCONF(NETDEV_UP): enp9s0: link is not ready [ 71.262391] IPv6: ADDRCONF(NETDEV_UP): enp9s0: link is not ready [ 74.272257] igb :09:00.0 enp9s0: igb: enp9s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX [ 74.487967] IPv6: ADDRCONF(NETDEV_CHANGE): enp9s0: link becomes ready [ 78.623864] igb :09:00.0 enp9s0: igb: enp9s0 NIC Link is Up 100 Mbps Half Duplex, Flow Control: None [ 78.623869] igb :09:00.0: EEE Disabled: unsupported at half duplex. Re-enable using ethtool when at full duplex. Then forcing with ehttool: # ethtool -s enp9s0 speed 1000 duplex full # dmesg | grep -E '(igb|eth|enp9s0)' ... [ 346.656896] igb :09:00.0 enp9s0: igb: enp9s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Any ideas would be much appreciated. Thanks. -- Nazar
Re: Zoom conferencing
On 2020-03-19 18:39, Anil Felipe Duggirala wrote: I have installed the flatpak with the latest version. I am running Debian 10 and Gnome. When trying to share the screen a message comes up saying that screen sharing is only available in Gnome on Wayland on Debian 9+,, and screen sharing does not start. I am baffled by this. Did you install this from the flatpak?? Yes, flatpak from flathub.org. I don't think any kind of screen sharing works in Wayland. I am using X11. (KDE Plasma, but that's irrelevant.) There should be an option to switch to Gnome X11 when logging in. -- Nazar
Re: Zoom conferencing
On 2020-02-29 23:08, Joel Rees wrote: (I hope no one gets upset about double posting debian and ubuntu users lists.) Questions about zoom --www.zoom.us Anyone using it? Issues? Known reasons they don't put it in the general repositories? As others have pointed out, it's proprietary and will never be in Debian and there are superior open-source alternatives. If the choice is not yours though, there is a flatpak for it: https://flathub.org/apps/details/us.zoom.Zoom. It's kept isolated from your system and it works. I haven't used video, but no issues with audio and screen sharing. -- Nazar
Re: 'synaptic' removed from buster
On 4/10/19 10:10 PM, David Wright wrote: On Thu 11 Apr 2019 at 00:34:04 (+0200), Nazar Zhuk wrote: On 4/10/19 10:58 AM, David Wright wrote: On Sat 06 Apr 2019 at 08:42:31 (+0100), Jonathan Dowland wrote: On Fri, Apr 05, 2019 at 09:39:23PM -0500, David Wright wrote: Given a straight toss-up though, I think synaptic has to give way because there are plenty of alternatives. I'd never heard of it until a few people started mentioning it here, and I'd never consider using it myself on X except as an ordinary user. The severity of the bug in synaptic (which is what has caused its autoremoval) would not be "serious" if the default desktop was not Wayland. So changing *that*, would mean synaptic could be reintroduced. So Debian should have its policy dictated by bugs in an unrelated package. Seems an odd strategy. If a change (Wayland default) is introducing issues to a stable (in a generic sense) system, shouldn't the change be postponed until the issues are resolved? Perhaps with the help from the change proponents. I don't think it's an issue that'll be resolved in the direction you intend. It's the enforcement of a security model that has guided most of us for years: not running GUI applications as root. In all of history of UNIX and Linux, root means root. You know what you are doing and accept the risks. rm -rf /, vim or wget under root are dangerous too. And Wayland doesn't actually change that, since nothing can, root is still root. You can do: xhost +SI:localuser:root and run whatever you want as root. This is exactly what the latest gparted does [1]. So this "security model" boils down to an annoyance. [1] https://gitlab.gnome.org/GNOME/gparted/blob/master/gparted.in#L70 The normal way of circumventing this is to have a non-GUI program that performs all the work running as root, with a connection to a GUI client program that runs as the user/administrator. Yes, that is the Wayland way. And it's now Wayland way or no way for all, not just Wayland users. ... for synaptic, it might be written in such a way that you can get the resolver to run with your friendly interface as an ordinary user, and then use apt-get, say, to install the list of packages that synaptic has come up with. ... Or just wrap it with a shell script that adds/removes root with xhost like gparted does, unless somebody has a compelling desire to *implement* (as opposed to force someone else to implement) "Wayland way". I tested this and it works like a charm. These are the things that should be considered and resolved when making a breaking change (Wayland default). -- Nazar
Re: 'synaptic' removed from buster
On 4/10/19 10:58 AM, David Wright wrote: On Sat 06 Apr 2019 at 08:42:31 (+0100), Jonathan Dowland wrote: On Fri, Apr 05, 2019 at 09:39:23PM -0500, David Wright wrote: Given a straight toss-up though, I think synaptic has to give way because there are plenty of alternatives. I'd never heard of it until a few people started mentioning it here, and I'd never consider using it myself on X except as an ordinary user. The severity of the bug in synaptic (which is what has caused its autoremoval) would not be "serious" if the default desktop was not Wayland. So changing *that*, would mean synaptic could be reintroduced. So Debian should have its policy dictated by bugs in an unrelated package. Seems an odd strategy. If a change (Wayland default) is introducing issues to a stable (in a generic sense) system, shouldn't the change be postponed until the issues are resolved? Perhaps with the help from the change proponents. -- Nazar
Re: Чому Debian не рекомендує встановлювати primary_hostname (exim) власноруч?
Привіт, On 4/1/19 10:30 AM, Yuri Kanivetsky wrote: Усім привіт. То лист undead чи half-life? :) https://lists.debian.org/debian-user-ukrainian/2006/11/msg1.html Тепер нас тут двоє. Краще спробую поставити питання... Нажаль не знаю відповіді. Якщо потрібно, можу перекласти на Англійську для debian-user@. -- Назар
Re: Security Updates
On Sun, Dec 30, 2018 at 08:00:51PM +0100, Marek Gráfel wrote: > I also tried the command via the apt-get update terminal, telling me that > the operation is declined. Make sure you run apt-get as root or with sudo: sudo apt-get update Then: sudo apt-get upgrade -- Nazar
Re: Session Recording
On Thu, Dec 27, 2018 at 05:35:13PM +0100, Ilyass Kaouam wrote: > > textual record of a series of commands and their output > Maybe this: https://asciinema.org/. There is a package in Debian. -- Nazar
Re: Apache and PHP-FPM
Hi, On Mon, Sep 24, 2018 at 05:52:28PM +0200, Martin LEUSCH wrote: > Hi, > > I have a web server with Apache 2.4 running in worker mode and multiple php > version with FPM service running in dynamic mode. > > Sometimes php-fpm stop responding and I got a 503 error on php request but > apache still respond to http request to other files (css, js, jpeg, ...) > then after a while apache stop respond (nothing logged on error log neither > in access log). I have to restart apache and php-fpm services to unlock the > server. Did you check php-fpm log as well? It's /var/log/php7.0-fpm.log in php-fpm package in stretch. > Off course it's append while I have malicious activity on the server, the > last time it's happen I found a SQL injection attempt that causing lot of > php error (maybe an infinite loop). I would consider what can be done to protect against these attacks in the code. This could be the root cause of the issue. > How can I avoid these kind of situation? Can I optimize actual settings? > Should I use mpm_event with apache and/or ondemand process manager with > PHP-FPM? > > > mpm_worker config: > > StartServers 2 > MinSpareThreads 25 > MaxSpareThreads 75 > ThreadLimit 64 > ThreadsPerChild 25 > MaxRequestWorkers 150 > MaxConnectionsPerChild 0 > > > php-fpm pool config: > > pm = dynamic > pm.max_children = 5 This could be a problem if you are getting spammed. Try increasing to see if it slows down the appearence of timeouts, but see above regarding code. > pm.start_servers = 2 > pm.min_spare_servers = 1 > pm.max_spare_servers = 3 > > > Thanks, > > Martin > -- Nazar
Re: Network manager and VPN
Hi, On Wed, Aug 29, 2018 at 07:49:38PM +0200, Jarosław Kłopotek - INTERDUO wrote: > Hi guys, > All the time when I disconnect all kind of VPN, there is a problem with DNS > Resolving. How are you connecting to VPN? If it's with network-manager-openvpn it should automatically restore your DNS to a configuration prior to connecting VPN. Look in /etc/resolv.conf before, during and after VPN connection. After should be restored to the state before. If you are using something other then network-manager-openvpn, it should restore resolv.conf for you or you may need to manually script that. > I use network manager 1.12.2. -- Nazar
