emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#64653: closed (‘static-networking’ fails to start)


From: GNU bug Tracking System
Subject: bug#64653: closed (‘static-networking’ fails to start)
Date: Fri, 05 Jan 2024 16:33:02 +0000

Your message dated Fri, 05 Jan 2024 17:32:18 +0100
with message-id <87r0iveo6l.fsf@gnu.org>
and subject line Re: bug#64653: ‘static-networking’ fails to start
has caused the debbugs.gnu.org bug report #64653,
regarding ‘static-networking’ fails to start
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
64653: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64653
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: ‘static-networking’ fails to start Date: Sat, 15 Jul 2023 22:04:59 +0200 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Hi!

On the machine that exhibited <https://issues.guix.gnu.org/63516>, I’m
now seeing this, with the fix from commit
26602f4063a6e0c626e8deb3423166bcd0abeb90:

--8<---------------cut here---------------start------------->8---
[  121.017522] shepherd[1]: Starting service user-homes...
[  121.049038] tg3 0000:05:00.0 eth0: Tigon3 [partno(BCM95720) rev 5720000] 
(PCI Express) MAC address b8:cb:29:b5:1c:3a
[  121.049042] tg3 0000:05:00.0 eth0: attached PHY is 5720C (10/100/1000Base-T 
Ethernet) (WireSpeed[1], EEE[1])
[  121.049044] tg3 0000:05:00.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] 
TSOcap[1]
[  121.049045] tg3 0000:05:00.0 eth0: dma_rwctrl[00000001] dma_mask[64-bit]
[  121.084342] tg3 0000:05:00.1 eth1: Tigon3 [partno(BCM95720) rev 5720000] 
(PCI Express) MAC address b8:cb:29:b5:1c:3b
[  121.084355] tg3 0000:05:00.1 eth1: attached PHY is 5720C (10/100/1000Base-T 
Ethernet) (WireSpeed[1], EEE[1])
[  121.084363] tg3 0000:05:00.1 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] 
TSOcap[1]
[  121.084370] tg3 0000:05:00.1 eth1: dma_rwctrl[00000001] dma_mask[64-bit]
[  121.102367] iTCO_vendor_support: vendor-support=0
[  121.103831] Error: Driver 'pcspkr' is already registered, aborting...
[  121.108617] dcdbas dcdbas: Dell Systems Management Base Driver (version 
5.6.0-3.4)
[  121.113037] tg3 0000:05:00.1 eno2: renamed from eth1

[...]

[  121.281600] shepherd[1]: Service user-homes has been started.
[  121.282538] shepherd[1]: Service user-homes started.
[  121.368316] ipmi_si IPI0001:00: Using irq 10
[  121.405790] ipmi_si IPI0001:00: IPMI message handler: Found new BMC (man_id: 
0x0002a2, prod_id: 0x0100, dev_id: 0x20)
[  121.419871] shepherd[1]: Exception caught while starting #<<service> 
7f19889012a0>: (wrong-type-arg "port-filename" "Wrong type argument in position 
~A: ~S" (1 #<closed: file 7f1981887000>) (#<closed: file 7f1981887000>))
[  121.420074] shepherd[1]: Service user-homes running with value #t.
[  121.420218] shepherd[1]: Service networking failed to start.
--8<---------------cut here---------------end--------------->8---

The failure seems to happen after the whole static networking config has
been set up though (‘ip a’ shows that everything’s in place).

Problem is that at this point ‘networking’ cannot be started unless you
manually tear down everything with ‘ip’:

--8<---------------cut here---------------start------------->8---
$ sudo herd start networking
herd: error: exception rattrapée pendant l’exécution de « start » sur le 
service « networking » :
Throw to key `%exception' with args `("#<&netlink-response-error errno: 17>")'.
--8<---------------cut here---------------end--------------->8---

(17 = EEXIST)

This makes me think we should make the set up phase idempotent or,
alternatively, add special actions to force a change.

Thoughts?

Ludo’.



--- End Message ---
--- Begin Message --- Subject: Re: bug#64653: ‘static-networking’ fails to start Date: Fri, 05 Jan 2024 17:32:18 +0100 User-agent: Gnus/5.13 (Gnus v5.13)
Hi!

Ludovic Courtès <ludo@gnu.org> skribis:

> Evaluating user expression (catch #t (lambda () (load "/gnu/store/64?")) # ?).
> starting 
> '/gnu/store/gn8q7p790a9zdnlciyp1vlncpin366r0-hurd-v0.9.git20230216/hurd/pfinet
>  "--ipv6" "/servers/socket/26" "--interface" "/dev/eth0" "--address" 
> "10.0.2.15" "--netmask" "255.255.255.0" "--gateway" "10.0.2.2"'
> In ice-9/boot-9.scm:
>     142:2  7 (dynamic-wind #<procedure 20393a0 at ice-9/eval.scm:33?> ?)
> In shepherd/support.scm:
>    486:15  6 (_ #<closed: file 50a7e38>)
> In ice-9/read.scm:
>    859:19  5 (read _)
> In unknown file:
>            4 (port-filename #<closed: file 50a7e38>)
> In ice-9/boot-9.scm:
>   1685:16  3 (raise-exception _ #:continuable? _)
>   1780:13  2 (_ #<&compound-exception components: (#<&assertion-fail?>)
> In ice-9/eval.scm:
>     159:9  1 (_ #(#(#<module (#{ g171}#) 3cd25f0>) (# "port-fil?" ?)))
> In unknown file:
>            0 (make-stack #t)
> #t
>
> So it’s indeed ‘read’ as called from ‘primitive-load*’ that stumbles
> upon a closed port.

Good news: this is fixed by 4e431fda5f2ec76b6d6a271be7c30b1324431329!
Silly me had introduced a ‘dynamic-wind’ there.

(The funny thing with extensible systems like the Shepherd is that the
problem can be anywhere.  :-))

Ludo’.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]