Re: Allocate tty1 for kernel messages
On 2022-09-25 17:52, basti wrote: > Am 25.09.22 um 17:25 schrieb David Wright: >> On Sun 25 Sep 2022 at 17:01:23 (+0200), Dmitry Katsubo wrote: >>> I am trying to make a following setup on Debian bullseye: >>> >>> * tty1 is used to display kernel messages only >>> * tty[2-5] are allocated for login >>> >>> I have modified /etc/default/console-setup so that it reads: >>> >>> ACTIVE_CONSOLES="/dev/tty[2-5]" >>> >>> and rebooted. What I observe is that tty1 displays kernel messages during >>> the boot (OK) but also ends with an invitation for login on tty1 (WRONG). >>> >>> How can I force that tty1 is not used for login? >> >> I think you still need to run: >> >> # dpkg-reconfigure console-setup >> >> to get that variable enacted. Then check that the file >> /etc/console-setup/cached_setup_keyboard.sh, which AIUI >> is what does the work, has been modified. >> >> That's similar for a lot of configuration parameters >> in /etc/default/. David, thanks for your input. I have run "dpkg-reconfigure console-setup" and rebooted and it didn't help. > Hello, > > first of all disable login on tty1: > > systemctl disable getty@tty1.service I have disabled and stopped this service: # systemctl status getty@tty1.service ● getty@tty1.service - Getty on tty1 Loaded: loaded (/lib/systemd/system/getty@.service; disabled; vendor preset: enabled) Drop-In: /etc/systemd/system/getty@.service.d └─noclear.conf Active: inactive (dead) Docs: man:agetty(8) man:systemd-getty-generator(8) http://0pointer.de/blog/projects/serial-console.html Sep 26 00:10:34 debian systemd[1]: Started Getty on tty1. Sep 26 01:20:43 debian systemd[1]: Stopping Getty on tty1... Sep 26 01:20:43 debian systemd[1]: getty@tty1.service: Succeeded. Sep 26 01:20:43 debian systemd[1]: Stopped Getty on tty1. I believe after that the "login:" prompt should disappear from tty1, but it didn't. Should I reboot to make this setting active? > Then in /etc/systemd/journald.conf: > (or in one of the conf.d folders, see man journald.conf.d) > > ForwardToConsole=yes > TTYPath=/dev/tty1 > > Will do it. That will forward kernel messages to tty1, right? -- With best regards, Dmitry
Allocate tty1 for kernel messages
Dear Debian users, I am trying to make a following setup on Debian bullseye: * tty1 is used to display kernel messages only * tty[2-5] are allocated for login I have modified /etc/default/console-setup so that it reads: ACTIVE_CONSOLES="/dev/tty[2-5]" and rebooted. What I observe is that tty1 displays kernel messages during the boot (OK) but also ends with an invitation for login on tty1 (WRONG). How can I force that tty1 is not used for login? Thanks in advance. Similar topics: * https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1789170 * https://forum.proxmox.com/threads/newb-question-console-setup-tty-changed-but-not-taking-effect.83368/ * https://unix.stackexchange.com/questions/198791/how-do-i-permanently-change-the-console-tty-font-type-so-it-holds-after-reboot -- With best regards, Dmitry
Re: /dev/dvb do not exist
On 2022-09-21 19:59, Thierry Leurent wrote: > Hello, > > I'm trying to configure an FM/DAB/DVB stick, it's an r820t using an rtl2838 > chip. > I'm able to listen fm radios. > When I use w_scan, it is not able to find the folder /dev/dvb. > > How can I create this ? > > Thanks > > Thierry Hello, How do you perform the channel scanning? E.g. * Install [dvb-apps](http://packages.debian.org/dvb-apps) and perform the channel scanning: $ scan /usr/share/dvb/dvb-t/nl-All > channels.conf You will see among other staff something like this: >>> tune to: >>> 72200:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_1_2:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE 0x 0x044d: pmt_pid 0x1b62 Digitenne -- Nederland 1 (running) 0x 0x044e: pmt_pid 0x1b6c Digitenne -- Nederland 2 (running) 0x 0x044f: pmt_pid 0x1b76 Digitenne -- Nederland 3 (running) 0x 0x0450: pmt_pid 0x1b80 Digitenne -- TV West (running) 0x 0x0457: pmt_pid 0x1bc6 Digitenne -- Radio West (running) 0x 0x0458: pmt_pid 0x1bd0 Digitenne -- Radio 1 (running) 0x 0x0459: pmt_pid 0x1bda Digitenne -- Radio 2 (running) 0x 0x045a: pmt_pid 0x1be4 Digitenne -- 3FM (running) 0x 0x045b: pmt_pid 0x1bee Digitenne -- Radio 4 (running) 0x 0x045c: pmt_pid 0x1bf8 Digitenne -- Radio 5 (running) 0x 0x045d: pmt_pid 0x1c02 Digitenne -- Radio 6 (running) 0x 0x045f: pmt_pid 0x1c16 Digitenne -- FunX (running) Network Name 'Digitenne' * Install any player that supports DVB on your wish (Xine, mplayer, Xawtv, Me TV7). For e.g. xine and mplayer copy the scanned channels information to ~/.xine/channels.conf and ~/.mplayer/channels.conf correspondingly. Launch the player: $ xine "dvb://Nederland 1" * Enjoy :) -- With best regards, Dmitry
Re: networking.service fails
On 2022-04-11 07:56, Reco wrote: > Good news - it explains "ifup: unknown interface eth0" messages. > Bad news - this /e/n/i is not valid. > > The reason being - both eth0 and eth1 lack interface definitions, i.e. > have no "iface" stanzas. > > If you absolutely need both eth0 and eth1 in the UP state by the time > you create and bring up br0 you should either: > > 1) Define both eth0 and eth1 in /e/n/i like this: > > auto eth0 > iface eth0 inet manual > > auto eth1 > iface eth1 inet manual > > auto br0 > iface br0 inet static > address 10.0.1.100 > gateway 10.0.1.1 > netmask 255.0.0.0 > bridge_ports eth0 eth1 > bridge_maxwait 60 > > 2) Use pre-up and post-down hooks for br0, and remove both "auto eth0" > and "auto eth1": > > auto br0 > iface br0 inet static > address 10.0.1.100 > gateway 10.0.1.1 > netmask 255.0.0.0 > bridge_ports eth0 eth1 > bridge_maxwait 60 > pre-up /sbin/ip link set eth0 up > pre-up /sbin/ip link set eth1 up > post-down /sbin/ip link set eth0 down > post-down /sbin/ip link set eth1 down > > Reco Hooray, it worked! Thanks for pointing out the configuration error. After fixing it everything worked like a charm. Would be very tricky for me to locate the issue... If the configuration is invalid, networking.service could probably complain about that? I would be able then to resolve the issue myself. Just for my record the reference to documentation: https://wiki.debian.org/BridgeNetworkConnections#Configuring_bridging_in_.2Fetc.2Fnetwork.2Finterfaces -- With best regards, Dmitry
Re: networking.service fails
Dear Debian community, First of all many thanks to everybody who has replied to my message and contributed ideas to solve the issue. On 3 Apr 2022 22:41:44, Greg Wooledge wrote: > So... you've got some wild stuff going on here. > > You have two interfaces. One of them was named enp2s0 and then got > renamed to eth0, which is usually the opposite direction from what one > expects. > > The other was named enp3s0 and then got renamed to eth1. Which, again, > is the opposite of what one expects. > > Normally, the kernel assigns the name eth0 temporarily to the first > interface that it finds, and then renames it to some "predictable" > name according to obtuse schemes. In your case, I'm imagining that > your interface started as eth0, then got renamed to enp2s0, then renamed > a second time back to eth0. > > At the time when ifup tried to run, the interface was named enp2s0, but > your configuration tried to address it by the name eth0. > > So, there are many questions here. > > How many different interface configuration schemes are you using here? > Which ones are they? > > a) Do you set the net.ifnames kernel parameter? If so, what value are >you setting it to? No, in my initial setup I didn't have this parameter. > b) Do you have any non-loopback interfaces configured in the >/etc/network/interfaces file? If so, which ones, and how are >they configured? The configuration is trivial: it adds both eth0 eth1 to the bridge br0. === cut /etc/network/interfaces === auto lo auto eth0 auto eth1 iface lo inet loopback auto br0 iface br0 inet static address 10.0.1.100 gateway 10.0.1.1 netmask 255.0.0.0 bridge_ports eth0 eth1 bridge_maxwait 60 === cut === > c) Do you have an /etc/udev/rules.d/70-persistent-net.rules file? Note >that this file was deprecated in buster. If it continued to work in >buster, that was just a happy accident. If it stopped working in >bullseye, that is not a surprise. In my initial setup I had this file. > d) Do you have any /etc/systemd/network/*.link files? If so, what's in >them? No, no files in that directory. > e) Do you have network-manager installed? If so, I don't know what >followup questions to ask about it, because I don't use it. No, I don't have network-manager installed. > f) Do you have any /etc/systemd/network/*.network files? If so, what's >in those? No, no files in that directory. > g) Do you have any *other* interface configuration schemes in play that >I don't know about? Nothing special I can think about. > Once you've identified all of the moving parts in this puzzle, then you > can figure out which ones you actually want to keep, and which ones > you should rip out. > > For comparison, my system (Debian 11 bullseye) has one interface. I > configure its name using a file in /etc/systemd/network/ which sets > the name to lan0. Then I configure its in /etc/network/interfaces > using that name. > > Some relevant log file lines: > > Mar 26 08:01:54 unicorn kernel: [1.042579] r8169 :02:00.0 eth0: > RTL8168gu/8111gu, 18:60:24:77:5c:ec, XID 509, IRQ 127 > [...] > Mar 26 08:01:54 unicorn kernel: [1.057022] r8169 :02:00.0 lan0: > renamed from eth0 > [...] > Mar 26 08:01:59 unicorn kernel: [ 20.372606] r8169 :02:00.0 lan0: Link > is Up - 100Mbps/Full - flow control rx/tx > > That's just one of many possible ways to configure network interfaces. > You might be using a different scheme. The important thing is that > you pick *one* scheme and set it up correctly. If you've got two or > more competing schemes in play, and they're undoing each other's work, > that's not desirable. > > It's also worth pointing out that /etc/udev/rules.d/70-persistent-net.rules > was deprecated in buster (Debian 10). According to the release notes, > it *may* work, or it may not. Users were instructed to migrate away > from it. > > It would not surprise me one bit if there's a race condition which causes > the renaming done by 70-persistent-net.rules to occur at the wrong time, > if it even happens at all. Greg, thanks for your remarks and questions – I have learned something new while looking here and there. On 4 Apr 2022 08:50:42, Reco wrote: > As /var/log/messages helpfully show, your udev rules work. > The problem is, next thing udev does is renaming your network interfaces > back to (Un)Predictable Naming™ scheme. > > Thus whatever stanzas you have in your interfaces(5) about eth0 and eth1 > fail, thus the whole networking.service fails. > > > The conclusion is simple too: > > 1) Remove 70-persistent-net.rules, it's not doing what it should anyway. > > 2) Either use (Un)Predictable Network names in your interfaces, such as > enp2s0 and enp3s0. > > 3) Or use systemd network link files to rename network interfaces. > > 4) Or add "net.ifnames=0" to kernel's cmdline, as others suggested. > > Reco Reco, I have applied (1) and (2), namely what I did: * Add
Re: networking.service fails
: wlan0: AP-ENABLED Apr 4 00:37:29 debian hostapd[1627]: wlan0: interface state UNINITIALIZED->ENABLED Apr 4 00:37:29 debian kernel: [ 22.487228] br0: port 3(wlan0) entered blocking state Apr 4 00:37:29 debian kernel: [ 22.487233] br0: port 3(wlan0) entered disabled state Apr 4 00:37:29 debian kernel: [ 22.487279] device wlan0 entered promiscuous mode Apr 4 00:37:29 debian kernel: [ 22.487298] br0: port 3(wlan0) entered blocking state Apr 4 00:37:29 debian kernel: [ 22.487299] br0: port 3(wlan0) entered forwarding state Apr 4 00:37:29 debian kernel: [ 22.676802] br0: port 1(eth0) entered disabled state Apr 4 00:37:29 debian kernel: [ 22.676917] br0: port 2(eth1) entered disabled state Apr 4 00:37:29 debian systemd[1]: Failed to start Raise network interfaces. Apr 4 00:37:29 debian systemd[1]: networking.service: Failed with result 'exit-code'. Apr 4 00:37:29 debian systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE Apr 4 00:37:31 debian kernel: [ 24.515701] r8169 :02:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx Apr 4 00:37:31 debian kernel: [ 24.515722] br0: port 1(eth0) entered blocking state Apr 4 00:37:31 debian kernel: [ 24.515727] br0: port 1(eth0) entered forwarding state What confuses me is that hostapd is configured to run after network.target, but in fact is running together with it. Maybe there is a side effect when hostapd adds wlan0 to br0? On 2021-02-17 15:38, Gary Dale wrote: > On 2021-02-17 08:28, Andrei POPESCU wrote: >> On Mi, 17 feb 21, 00:01:01, Gary Dale wrote: >>> On 2021-02-16 19:44, Dmitry Katsubo wrote: >>>> Dear Debian community, >>>> >>>> I am puzzled with the following problem. When my Debian 10.8 starts, the >>>> unit "networking.service" is >>>> marked as failed with the following reason: >>>> >>>> root@debian:~ # systemctl status networking.service >>>> *— networking.service - Raise network interfaces >>>> Loaded: loaded (/lib/systemd/system/networking.service; enabled; >>>> vendor preset: enabled) >>>> Active: failed (Result: exit-code) since Tue 2021-02-16 08:56:16 CET; >>>> 5h 27min ago >>>> Docs: man:interfaces(5) >>>> Process: 691 ExecStart=/sbin/ifup -a --read-environment (code=exited, >>>> status=1/FAILURE) >>>> Main PID: 691 (code=exited, status=1/FAILURE) >>> Debian/Busteris still using Network Manager not systemd to control the >>> network so I think the network.service shouldn't be used. >> Well, systemd as init is starting everything so that necessarily >> includes starting "the network", which in practice means starting >> whatever network management framework is in use[1]. >> >> The 'networking.service' service is part of ifupdown, Debian's default >> network management framework (Priority: important). >> >> Network Manager is Priority: optional and typically installed as a >> Depends/Recommends of Desktop Environments. >> >> [1] this is applicable even for systemd's own network management >> framework systemd-networkd, which is included in the 'systemd' Debian >> package, but not activated by default. >> >> Kind regards, >> Andrei > Sorry, it was midnight when I replied. However the failure is likely still > due to the interfaces misconfiguration - probably reporting a failure to > raise a non-existent interface. > On 2021-02-17 07:55, Reco wrote: > Try running this: > > ifdown -a --force > ifup -a -v > > Last command should show you the source of the trouble. > > Reco Reco, here is the log: # ifdown -a --force; ifup -a -v /bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d run-parts: executing /etc/network/if-pre-up.d/bridge run-parts: executing /etc/network/if-pre-up.d/ethtool run-parts: executing /etc/network/if-pre-up.d/hostapd run-parts: executing /etc/network/if-pre-up.d/wireless-tools run-parts: executing /etc/network/if-pre-up.d/wpasupplicant ifup: configuring interface lo=lo (inet) /bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d run-parts: executing /etc/network/if-pre-up.d/bridge run-parts: executing /etc/network/if-pre-up.d/ethtool run-parts: executing /etc/network/if-pre-up.d/hostapd run-parts: executing /etc/network/if-pre-up.d/wireless-tools run-parts: executing /etc/network/if-pre-up.d/wpasupplicant /sbin/ip link set dev lo up /bin/run-parts --exit-on-error --verbose /etc/network/if-up.d run-parts: executing /etc/network/if-up.d/avahi-autoipd run-parts: executing /etc/network/if-up.d/ethtool run-parts: executing /etc/network/if-up.d/wpasupplicant ifup: unknown in
Re: Some services cannot start at boot time because /run is not initialized
Dear Debian community, I have noticed that all failed services were missing some directories under /run directory. I checked the service which is supposed to create them: * systemd-tmpfiles-setup.service - Create Volatile Files and Directories Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; static; vendor preset: enabled) Active: inactive (dead) Docs: man:tmpfiles.d(5) man:systemd-tmpfiles(8) systemd[1]: sysinit.target: Found ordering cycle on systemd-tmpfiles-setup.service/start systemd[1]: sysinit.target: Found dependency on local-fs.target/start systemd[1]: sysinit.target: Found dependency on zram-setup@zram1.service/start systemd[1]: sysinit.target: Found dependency on sysinit.target/start systemd[1]: sysinit.target: Job systemd-tmpfiles-setup.service/start deleted to break ordering cycle starting with sysinit.target/start and it looks like there is problem in zram-setup@zram1.service which I configured like that: [Unit] Requires=dev-%i.device After=dev-%i.device Before=local-fs.target [Install] WantedBy=local-fs.target # systemctl show -p Requires,Wants,Requisite,BindsTo,PartOf,Before,After local-fs.target Requires=home.mount -.mount var.mount Requisite= Wants=systemd-fsck-root.service zram-setup@zram0.service zram-setup@zram1.service systemd-remount-fs.service BindsTo= PartOf= Before=binfmt-support.service sysinit.target systemd-machine-id-commit.service systemd-tmpfiles-setup.service networking.service systemd-tmpfiles-clean.service console-setup.service After=run-user-1000.mount zram-setup@zram0.service root.mount -.mount tmp.mount zram-setup@zram1.service systemd-fsck-root.service systemd-remount-fs.service home.mount var.mount local-fs-pre.target Even though I don't see any conflict with dependencies, it is confusing systemd. Any idea concerning how to fix that is welcomed. On 2020-06-29 01:37, Dmitry Katsubo wrote: > Dear Debian community, > > I hit the similar problem but this time with /run folder. Few services have > failed to start: > > # systemctl status php7.0-fpm.service > Jun 24 23:09:48 debian php-fpm7.0[893]: [24-Jun-2020 23:09:48] ERROR: unable > to bind listening socket for address '/run/php/php7.0-fpm.sock': No such file > or directory (2) > Jun 24 23:09:48 debian php-fpm7.0[893]: [24-Jun-2020 23:09:48] ERROR: FPM > initialization failed > Jun 24 23:09:48 debian systemd[1]: php7.0-fpm.service: Main process exited, > code=exited, status=78/CONFIG > Jun 24 23:09:48 debian systemd[1]: php7.0-fpm.service: Failed with result > 'exit-code'. > Jun 24 23:09:48 debian systemd[1]: Failed to start The PHP 7.0 FastCGI > Process Manager. > > # systemctl status motioneye.service > Jun 24 23:09:47 debian systemd[1]: Started motionEye Server. > Jun 24 23:09:48 debian meyectl[895]: INFO: hello! this is motionEye > server 0.41 > Jun 24 23:09:48 debian meyectl[895]: CRITICAL: pid directory "/run/motioneye" > does not exist or is not writable > Jun 24 23:09:48 debian systemd[1]: motioneye.service: Main process exited, > code=exited, status=255/EXCEPTION > Jun 24 23:09:48 debian systemd[1]: motioneye.service: Failed with result > 'exit-code'. > > # cat /etc/tmpfiles.d/php.conf > d /run/php/sessions 1733 root root > > # cat /etc/tmpfiles.d/motioneye.conf > d /run/motioneye 0750 motion motion > > Just after the boot I have inspected /run folder. It was created/mounted > correctly and there have been a lot of files/directories there. I suspect that > all services that have created the necessary directory under /run were able to > start normally. Few of them which relied on existence of specific directory, > have failed to started. After I have replayed the corresponding instructions > for > tmpfiles.d, the services have started normally. > > I have a feeling that systemd-tmpfiles was executed before /run was mounted. > > Needless to note that the problem is not persistent: sometimes OS boots > without > a single failed service. > > How can I debug the problem? > > Thank you! > > On 2020-05-18 02:39, Dmitry Katsubo wrote: >> On 2020-05-11 20:11, Darac Marjal wrote: >>> On 11/05/2020 08:40, Reco wrote: >>>>Hi. >>>> >>>> On Mon, May 11, 2020 at 09:33:59AM +0200, Dmitry Katsubo wrote: >>>> >>>>> root@debian:~ # systemctl status binfmt-support >>>>> * binfmt-support.service - Enable support for additional executable >>>>> binary formats >>>>>Loaded: loaded (/lib/systemd/system/binfmt-support.service; enabled; >>>>> vendor preset: enabled) >>>>>Active: failed (Result: exit-code) since Sun 2020-05-10 21:54:27 CEST; >>>>> 10h ago >&g
networking.service fails
Dear Debian community, I am puzzled with the following problem. When my Debian 10.8 starts, the unit "networking.service" is marked as failed with the following reason: root@debian:~ # systemctl status networking.service *— networking.service - Raise network interfaces Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2021-02-16 08:56:16 CET; 5h 27min ago Docs: man:interfaces(5) Process: 691 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE) Main PID: 691 (code=exited, status=1/FAILURE) however network is working just fine. I looked into /usr/lib/systemd/system/networking.service where TimeoutStartSec=5min and also set a big timeout for br0 in /etc/network/interfaces: auto lo auto eth0 auto eth1 iface lo inet loopback auto br0 iface br0 inet static ... bridge_ports eth0 eth1 bridge_maxwait 60 but still the error occurs each time. Relative dmesg logs are: Feb 16 08:56:16 debian systemd[1]: Starting Raise network interfaces... Feb 16 08:56:16 debian ifup[691]: ifup: unknown interface eth0 Feb 16 08:56:16 debian ifup[691]: ifup: unknown interface eth1 Feb 16 08:56:16 debian ifup[691]: Waiting for br0 to get ready (MAXWAIT is 60 seconds). Feb 16 08:56:16 debian systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE Feb 16 08:56:16 debian systemd[1]: networking.service: Failed with result 'exit-code'. Feb 16 08:56:16 debian systemd[1]: Failed to start Raise network interfaces. Feb 16 08:56:16.113716 debian systemd-udevd[387]: Using default interface naming scheme 'v240'. Feb 16 08:56:16.113796 debian systemd-udevd[387]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. Feb 16 08:56:16.113851 debian systemd-udevd[387]: Could not generate persistent MAC address for br0: No such file or directory Feb 16 08:56:16.115750 debian kernel: bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this Feb 16 08:56:16.115828 debian kernel: br0: port 1(eth0) entered blocking state Feb 16 08:56:16.115875 debian kernel: br0: port 1(eth0) entered disabled state Feb 16 08:56:16.115929 debian kernel: device eth0 entered promiscuous mode Feb 16 08:56:16.119800 debian kernel: r8169 :02:00.0: firmware: direct-loading firmware rtl_nic/rtl8168g-2.fw Feb 16 08:56:16.120198 debian kernel: Generic PHY r8169-200:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=r8169-200:00, irq=IGNORE) Feb 16 08:56:16.251795 debian kernel: br0: port 2(eth1) entered blocking state Feb 16 08:56:16.251990 debian kernel: br0: port 2(eth1) entered disabled state Feb 16 08:56:16.391879 debian kernel: br0: port 1(eth0) entered blocking state Feb 16 08:56:16.391913 debian kernel: br0: port 1(eth0) entered forwarding state Feb 16 08:56:16.516862 debian systemd[1]: Starting Hostname Service... Feb 16 08:56:16.539520 debian systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE Feb 16 08:56:16.539612 debian systemd[1]: networking.service: Failed with result 'exit-code'. Feb 16 08:56:16.539994 debian systemd[1]: Failed to start Raise network interfaces. Feb 16 08:56:16.671750 debian kernel: br0: port 3(wlan0) entered blocking state Feb 16 08:56:16.671808 debian kernel: br0: port 3(wlan0) entered disabled state Feb 16 08:56:16.671844 debian kernel: device wlan0 entered promiscuous mode Feb 16 08:56:16.671878 debian kernel: br0: port 3(wlan0) entered blocking state Feb 16 08:56:16.671912 debian kernel: br0: port 3(wlan0) entered forwarding state Feb 16 08:56:16.683579 debian hostapd[879]: wlan0: interface state UNINITIALIZED->ENABLED Feb 16 08:56:16.683579 debian hostapd[879]: wlan0: AP-ENABLED Any ideas where can I take a look? Thanks in advance! -- With best regards, Dmitry
Re: Some services cannot start at boot time because /run or /var is not mounted
Dear Debian community, I hit the similar problem but this time with /run folder. Few services have failed to start: # systemctl status php7.0-fpm.service Jun 24 23:09:48 debian php-fpm7.0[893]: [24-Jun-2020 23:09:48] ERROR: unable to bind listening socket for address '/run/php/php7.0-fpm.sock': No such file or directory (2) Jun 24 23:09:48 debian php-fpm7.0[893]: [24-Jun-2020 23:09:48] ERROR: FPM initialization failed Jun 24 23:09:48 debian systemd[1]: php7.0-fpm.service: Main process exited, code=exited, status=78/CONFIG Jun 24 23:09:48 debian systemd[1]: php7.0-fpm.service: Failed with result 'exit-code'. Jun 24 23:09:48 debian systemd[1]: Failed to start The PHP 7.0 FastCGI Process Manager. # systemctl status motioneye.service Jun 24 23:09:47 debian systemd[1]: Started motionEye Server. Jun 24 23:09:48 debian meyectl[895]: INFO: hello! this is motionEye server 0.41 Jun 24 23:09:48 debian meyectl[895]: CRITICAL: pid directory "/run/motioneye" does not exist or is not writable Jun 24 23:09:48 debian systemd[1]: motioneye.service: Main process exited, code=exited, status=255/EXCEPTION Jun 24 23:09:48 debian systemd[1]: motioneye.service: Failed with result 'exit-code'. # cat /etc/tmpfiles.d/php.conf d /run/php/sessions 1733 root root # cat /etc/tmpfiles.d/motioneye.conf d /run/motioneye 0750 motion motion Just after the boot I have inspected /run folder. It was created/mounted correctly and there have been a lot of files/directories there. I suspect that all services that have created the necessary directory under /run were able to start normally. Few of them which relied on existence of specific directory, have failed to started. After I have replayed the corresponding instructions for tmpfiles.d, the services have started normally. I have a feeling that systemd-tmpfiles was executed before /run was mounted. Needless to note that the problem is not persistent: sometimes OS boots without a single failed service. How can I debug the problem? Thank you! On 2020-05-18 02:39, Dmitry Katsubo wrote: > On 2020-05-11 20:11, Darac Marjal wrote: >> On 11/05/2020 08:40, Reco wrote: >>> Hi. >>> >>> On Mon, May 11, 2020 at 09:33:59AM +0200, Dmitry Katsubo wrote: >>> >>>> root@debian:~ # systemctl status binfmt-support >>>> * binfmt-support.service - Enable support for additional executable >>>> binary formats >>>>Loaded: loaded (/lib/systemd/system/binfmt-support.service; enabled; >>>> vendor preset: enabled) >>>>Active: failed (Result: exit-code) since Sun 2020-05-10 21:54:27 CEST; >>>> 10h ago >>>> Docs: man:update-binfmts(8) >>>> Process: 353 ExecStart=/usr/sbin/update-binfmts --enable (code=exited, >>>> status=2) >>>> Main PID: 353 (code=exited, status=2) >>>> >>>> May 10 21:54:27 debian update-binfmts[353]: update-binfmts: unable to open >>>> /var/lib/binfmts: No such file or directory >>>> >>>> Any help is appreciated. >>> This should help your problem: >>> >>> mkdir /etc/systemd/system/binfmt-support.service.d >>> >>> cat > /etc/systemd/system/binfmt-support.service.d/override.conf << EOF >>> [Unit] >>> RequiresMountsFor=/var >>> EOF >> >> As another alternative, one can run "systemctl edit >> binfmt-support.service", which will create the intervening folders and >> files for you, and reload the daemon if the editor exits with success. > > Thanks for suggestion! I have tried the advise and it actually worked > (I will keep an eye on that because one reboot may not be representative). > I wonder nevertheless what is the problem with this specific unit? It has > dependency on local-fs.target which in turn should mount /var. So what > exactly went wrong? -- With best regards, Dmitry
Re: binfmt-support cannot start at boot time because /var is not mounted
On 2020-05-11 20:11, Darac Marjal wrote: > On 11/05/2020 08:40, Reco wrote: >> Hi. >> >> On Mon, May 11, 2020 at 09:33:59AM +0200, Dmitry Katsubo wrote: >> >>> root@debian:~ # systemctl status binfmt-support >>> * binfmt-support.service - Enable support for additional executable binary >>> formats >>>Loaded: loaded (/lib/systemd/system/binfmt-support.service; enabled; >>> vendor preset: enabled) >>>Active: failed (Result: exit-code) since Sun 2020-05-10 21:54:27 CEST; >>> 10h ago >>> Docs: man:update-binfmts(8) >>> Process: 353 ExecStart=/usr/sbin/update-binfmts --enable (code=exited, >>> status=2) >>> Main PID: 353 (code=exited, status=2) >>> >>> May 10 21:54:27 debian update-binfmts[353]: update-binfmts: unable to open >>> /var/lib/binfmts: No such file or directory >>> >>> Any help is appreciated. >> This should help your problem: >> >> mkdir /etc/systemd/system/binfmt-support.service.d >> >> cat > /etc/systemd/system/binfmt-support.service.d/override.conf << EOF >> [Unit] >> RequiresMountsFor=/var >> EOF > > As another alternative, one can run "systemctl edit > binfmt-support.service", which will create the intervening folders and > files for you, and reload the daemon if the editor exits with success. Thanks for suggestion! I have tried the advise and it actually worked (I will keep an eye on that because one reboot may not be representative). I wonder nevertheless what is the problem with this specific unit? It has dependency on local-fs.target which in turn should mount /var. So what exactly went wrong? -- With best regards, Dmitry
Re: binfmt-support cannot start at boot time because /var is not mounted
On 2020-05-11 20:11, Darac Marjal wrote: > On 11/05/2020 08:40, Reco wrote: >> Hi. >> >> On Mon, May 11, 2020 at 09:33:59AM +0200, Dmitry Katsubo wrote: >> >>> root@debian:~ # systemctl status binfmt-support >>> * binfmt-support.service - Enable support for additional executable binary >>> formats >>>Loaded: loaded (/lib/systemd/system/binfmt-support.service; enabled; >>> vendor preset: enabled) >>>Active: failed (Result: exit-code) since Sun 2020-05-10 21:54:27 CEST; >>> 10h ago >>> Docs: man:update-binfmts(8) >>> Process: 353 ExecStart=/usr/sbin/update-binfmts --enable (code=exited, >>> status=2) >>> Main PID: 353 (code=exited, status=2) >>> >>> May 10 21:54:27 debian update-binfmts[353]: update-binfmts: unable to open >>> /var/lib/binfmts: No such file or directory >>> >>> Any help is appreciated. >> This should help your problem: >> >> mkdir /etc/systemd/system/binfmt-support.service.d >> >> cat > /etc/systemd/system/binfmt-support.service.d/override.conf << EOF >> [Unit] >> RequiresMountsFor=/var >> EOF > > As another alternative, one can run "systemctl edit > binfmt-support.service", which will create the intervening folders and > files for you, and reload the daemon if the editor exits with success. Thanks for suggestion! I have tried the advise and it actually worked (I will keep an eye on that because one reboot may not be representative). I wonder nevertheless what is the problem with this specific unit? It has dependency on local-fs.target which in turn should mount /var. So what exactly went wrong? -- With best regards, Dmitry
binfmt-support cannot start at boot time because /var is not mounted
Dear Debian users, I am stuck with the following problem which I failed to debug on my Debian 10.3. In my setup I have /var as mounted volume: === /etc/fatab === UUID=83a3cb60-3334-4d11-9fdf-70b8e8703167/varbtrfs noatime,nodev,nosuid,subvol=var === end === Unfortunately sometimes I notice that binfmt-support is tried to be started "before" /var is mounted. Once I login and restart the service (I don't mount and/or repair anything), it starts just fine. === console === root@debian:~ # systemctl status binfmt-support * binfmt-support.service - Enable support for additional executable binary formats Loaded: loaded (/lib/systemd/system/binfmt-support.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Sun 2020-05-10 21:54:27 CEST; 10h ago Docs: man:update-binfmts(8) Process: 353 ExecStart=/usr/sbin/update-binfmts --enable (code=exited, status=2) Main PID: 353 (code=exited, status=2) May 10 21:54:27 debian update-binfmts[353]: update-binfmts: unable to open /var/lib/binfmts: No such file or directory root@debian:~ # ll /var/lib/binfmts total 16 drwxr-xr-x 1 root root 50 Mar 17 23:46 . drwxr-xr-x 1 root root 988 Mar 2 01:57 .. -rw-r--r-- 1 root root 49 Apr 14 2019 jar -rw-r--r-- 1 root root 59 Mar 17 23:46 python3.7 root@debian:~ # systemctl start binfmt-support root@debian:~ # systemctl status binfmt-support * binfmt-support.service - Enable support for additional executable binary formats Loaded: loaded (/lib/systemd/system/binfmt-support.service; enabled; vendor preset: enabled) Active: active (exited) since Mon 2020-05-11 09:01:04 CEST; 4s ago Docs: man:update-binfmts(8) Process: 9683 ExecStart=/usr/sbin/update-binfmts --enable (code=exited, status=0/SUCCESS) Main PID: 9683 (code=exited, status=0/SUCCESS) May 11 09:01:04 debian systemd[1]: Starting Enable support for additional executable binary formats... May 11 09:01:04 debian systemd[1]: Started Enable support for additional executable binary formats. root@debian:~ # dpkg -l | grep -i systemd ii systemd 241-7~deb10u3 amd64 system and service manager ... === end === One time the system was started with even more units failed because of inaccessible /var. There is nothing special in these units, and I haven't modified any *.service files. In other words the problem is floating, as number of failed unit varies from boot to boot. The difficulty is that I don't know how to debug system start / systemd at such early stage of system boot. Any help is appreciated. -- With best regards, Dmitry
Core dumps are instantly removed
Dear Debian users, Hopefully you can easily help me with my confusion. I would like to collect / keep core dumps in the system. For that I use systemd-coredump package which is configured as following: === cut /etc/systemd/coredump.conf === [Coredump] Storage=external MaxUse=5G === cut === Then I have created a script to send core dump report daily to root: === cut /etc/cron.daily/coredump === YESTERDAY=`date --date="1 day ago" +%Y-%m-%d` MESSAGE=`coredumpctl list --no-pager -r -S $YESTERDAY -U $(date +%Y-%m-%d) 2> /dev/null` && (echo "$MESSAGE"; echo -e "\nLast core dump info:\n"; coredumpctl info --no-pager; echo -e "\nCore dumps:\n"; ls -l /var/lib/systemd/coredump; ) | mail -s "Core dumps created yesterday $YESTERDAY" root === cut === What I get is: === cut === TIMEPID UID GID SIG COREFILE EXE Tue 2019-12-10 11:27:26 CET2537 1003 100 5 missing /usr/bin/light-locker Last core dump info: PID: 2537 (light-locker) ... Signal: 5 (TRAP) Timestamp: Tue 2019-12-10 11:27:25 CET (20h ago) Command Line: light-locker Executable: /usr/bin/light-locker ... Storage: /var/lib/systemd/coredump/core.light-locker.1003.810304...157597364500.lz4 (inaccessible) Message: Process 2537 (light-locker) of user 1003 dumped core. Stack trace of thread 2537: #0 0x7fde22515c75 n/a (libglib-2.0.so.0) #1 0x7fde22516d0d g_log_default_handler (libglib-2.0.so.0) #2 0x7fde22516f5f g_logv (libglib-2.0.so.0) #3 0x7fde2251714f g_log (libglib-2.0.so.0) #4 0x563b0e2f30a3 n/a (light-locker) #5 0x7fde22615107 g_type_create_instance (libgobject-2.0.so.0) ... Core dumps: total 0 === cut === As one can see, stack trace is somehow captured by coredumpctl (where it gets it from?) but core file is not there. I would like core dump files to be preserved for (say) 10 days. light-locker generates really tiny core dump when I start it from console: === cut === $ /usr/bin/light-locker Trace/breakpoint trap (core dumped) # ls -l /var/lib/systemd/coredump/ -rw-r-+ 1 root root 884992 Dec 13 14:16 core.light-locker.1003.8103...157624301300.lz4 === cut === Also I am aware about this setting: === cut /usr/lib/tmpfiles.d/systemd.conf === d /var/lib/systemd/coredump 0755 root root 3d === cut === but it configures the directory to be cleaned in three days while they are removed sooner. Any ideas? Thanks in advance! P.S. I have read: https://wiki.debian.org/HowToGetABacktrace#Core_dump https://wiki.archlinux.org/index.php/Core_dump but didn't find the answer. -- With best regards, Dmitry
Core dumps are instantly removed
Dear Debian users, Hopefully you can easily help me with my confusion. I would like to collect / keep core dumps in the system. For that I use systemd-coredump package which is configured as following: === cut /etc/systemd/coredump.conf === [Coredump] Storage=external MaxUse=5G === cut === Then I have created a script to send core dump report daily to root: === cut /etc/cron.daily/coredump === YESTERDAY=`date --date="1 day ago" +%Y-%m-%d` MESSAGE=`coredumpctl list --no-pager -r -S $YESTERDAY -U $(date +%Y-%m-%d) 2> /dev/null` && (echo "$MESSAGE"; echo -e "\nLast core dump info:\n"; coredumpctl info --no-pager; echo -e "\nCore dumps:\n"; ls -l /var/lib/systemd/coredump; ) | mail -s "Core dumps created yesterday $YESTERDAY" root === cut === What I get is: === cut === TIMEPID UID GID SIG COREFILE EXE Tue 2019-12-10 11:27:26 CET2537 1003 100 5 missing /usr/bin/light-locker Last core dump info: PID: 2537 (light-locker) ... Signal: 5 (TRAP) Timestamp: Tue 2019-12-10 11:27:25 CET (20h ago) Command Line: light-locker Executable: /usr/bin/light-locker ... Storage: /var/lib/systemd/coredump/core.light-locker.1003.810304...157597364500.lz4 (inaccessible) Message: Process 2537 (light-locker) of user 1003 dumped core. Stack trace of thread 2537: #0 0x7fde22515c75 n/a (libglib-2.0.so.0) #1 0x7fde22516d0d g_log_default_handler (libglib-2.0.so.0) #2 0x7fde22516f5f g_logv (libglib-2.0.so.0) #3 0x7fde2251714f g_log (libglib-2.0.so.0) #4 0x563b0e2f30a3 n/a (light-locker) #5 0x7fde22615107 g_type_create_instance (libgobject-2.0.so.0) ... Core dumps: total 0 === cut === As one can see, stack trace is somehow captured by coredumpctl (where it gets it from?) but core file is not there. I would like core dump files to be preserved for (say) 10 days. light-locker generates really tiny core dump when I start it from console: === cut === $ /usr/bin/light-locker Trace/breakpoint trap (core dumped) # ls -l /var/lib/systemd/coredump/ -rw-r-+ 1 root root 884992 Dec 13 14:16 core.light-locker.1003.8103...157624301300.lz4 === cut === Also I am aware about this setting: === cut /usr/lib/tmpfiles.d/systemd.conf === d /var/lib/systemd/coredump 0755 root root 3d === cut === but it configures the directory to be cleaned in three days while they are removed sooner. Any ideas? Thanks in advance! P.S. I have read: https://wiki.debian.org/HowToGetABacktrace#Core_dump https://wiki.archlinux.org/index.php/Core_dump but didn't find the answer. -- With best regards, Dmitry
