Re: em0 does not have time to get address
On Thu, May 14, 2020 at 11:19:04AM +0200, Andreas Kusalananda Kähäri wrote: > On Thu, May 14, 2020 at 10:43:56AM +0200, Kusalananda Kähäri wrote: > > >Synopsis: em0 does not get address from DHCP server in time > > >Category: system amd64 > > >Environment: > > System : OpenBSD 6.7 > > Details : OpenBSD 6.7-current (GENERIC.MP) #186: Thu May 14 > > 00:13:53 MDT 2020 > > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > Architecture: OpenBSD.amd64 > > Machine : amd64 > > >Description: > > > > In recent snapshots, it seems that em0 sometimes does not get a link > > and/or IP address from the DHCP server quick enough and the interface > > is left without a proper IP address. This has the knock-on effect that > > ntpd does not start properly, and, since it happened to the OpenBSD > > machine running my local unbound, my home network was left without being > > able to resolve local names, mount NFS shares, etc. Hi Andreas, More of a comment than a solution but it might still improve your case or provide you with a better workaround. To me that doesn't sounds like a matter of how quickly em0 get his IP from the DHCP server. It looks like the time it takes to get its status "active". Typically on my system an 'ifconfig em0 up' will take ~23s to get active, but less than ~3s if I just specify the media type and opts. To see your supported media type: # ifconfig em0 media You could then specify the media type in your /etc/hostname.em0 dhcp options options being something like : media 100baseTX mediaopt full-duplex This is well documented in hostname.if(5) and ifconfig(8). Hope this help. Cheers, -- clematis (0xA2C87EDB507B4C53)
Re: [arm64] rcctl start returns (ok) but daemon is not started
On Sun, Dec 22, 2019 at 09:53:08PM +0100, clematis wrote: > On Sun, Dec 22, 2019 at 07:30:50PM +0100, Jeremie Courreges-Anglas wrote: > > On Fri, Dec 20 2019, clematis wrote: > Someone else also asked me to try adding the -i lo0 option to > daemon_flags= but that doesn't change the result either. Ok this email thread can be closed. No bug. I screw up a first config once and the /var/run/rc.d/geomyidae file containing the error stayed there despite all other changes I was making. And it was removed during pkg_delete (and it reminds about user/group/logs and index but not that file in run/ which could be there if not stopped properly (I did pkill a few ones)) And for the record it should be "-i 127.0.0.1" and not "-i lo0" which I had probable since second version and that is what I was running from cmd line which is why it worked that way. Thanks to all those checking and bringing feedback through various channel. And sorry about the noise, pure user mistake. (I will remember to check /var/run/rc.d/ now if I have to kill a daemon manually and not stop it clean via rcctl) Regards, -- clematis (0x7e96fd2400fe7b59)
Re: [arm64] rcctl start returns (ok) but daemon is not started
On Sun, Dec 22, 2019 at 07:30:50PM +0100, Jeremie Courreges-Anglas wrote: > On Fri, Dec 20 2019, clematis wrote: > I suspect you have something funny in your /root/.profile (which is read > by the shell process that starts geomyidae). Does temporarily moving > away your /root/.profile fix the issue? Hi, /root/.profile is the default one[1] without any modification. They are the same on my amd64 and arm64 box. But again I can observe this problem only on arm64. Moving it away didn't change the result. > geomyidae starts properly with rcctl in a fresh vm here. It does as well on amd64. I've also tried to play around the pexp= definition in the rc script but that didn't make any changes, still this weird getaddrinfo (lo0:70): no address associated with name message only on arm64. (and only when trying to start with rcctl, don't get this with same arguments when starting straight from the prompt). Someone else also asked me to try adding the -i lo0 option to daemon_flags= but that doesn't change the result either. [1] $OpenBSD: dot.profile,v 1.9 2010/12/13 12:54:31 millert Exp $ Thanks, -- clematis (0x7e96fd2400fe7b59)
[arm64] rcctl start returns (ok) but daemon is not started
Synopsis: rcctl start returns (ok) but daemon is not started Category: rcctl / getaddrinfo Environment: System : OpenBSD 6.6 Details : OpenBSD 6.6-current (GENERIC.MP) #386: Wed Dec 18 14:42:08 MST 2019 dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP Architecture: OpenBSD.arm64 Machine : arm64 (it is a pine64-lts) Description: Starting the package geomyidae with rcctl start returns an (ok) but no geomyidae process is actually being started. Running directly geomyidae with options identical to the "daemon_flags=" of the rc script works just fine. How-To-Repeat: I can only repeat this issue on arm64. (Everything works as expected on amd64 similar -current from 18th Dec and same package version). # pkg_add geomyidae # rcctl start geomyidae geomyidae(ok) # ps aux|grep geomyidae => No daemon started despite the (ok) return. # rcctl -d start geomyidae doing _rc_parse_conf doing _rc_quirks geomyidae_flags empty, using default >-l /var/log/geomyidae.log -u _geomyidae -g _geomyidae< doing _rc_parse_conf /var/run/rc.d/geomyidae doing _rc_quirks doing rc_check geomyidae doing rc_start doing _rc_wait start doing rc_check getaddrinfo (lo0:70): no address associated with name doing _rc_write_runfile (ok) => what's this getaddrinfo message? ifconfig lo0 is absolutely standard /etc/hosts as well pf got a set skip on lo0 (same settings on the amd64 box on which I can't reproduce this). /var/log/geomyidae.log is setup with the right user and group. pkg_delete does delete properly the rc script. I've tried to reinstall the package, install goes OK but still won't start with rcctl. Fix: I don't have a fix. The workaround to start this specific package/daemon is to run it manually. # geomyidae -l /var/log/geomyidae.log -u _geomyidae -g _geomyidae (All other available options work too). Thanks. Regards, -- clematis (0x7e96fd2400fe7b59)
tmux default keybinding changes prevent moving to pane above/below
Synopsis: changes in tmux default keybinding affect pane navigation Category: system documentation Environment: System : OpenBSD 6.6 Details : OpenBSD 6.6-beta (GENERIC.MP) #314: Mon Sep 16 19:13:24 MDT 2019 Architecture: OpenBSD.amd64 Machine : amd64 Description: Hi Team, Recent changes to the tmux default keybinding UP/DOWN affect pane navigation. ctrl-b UP or ctrl-b DOWN doesn't allow to move to the pane above or below anymore. I suspect this being related to changes in: tmux/key-bindings.c Revision 1.100, Mon Sep 16 13:27:14 2019 UTC tmux/menu.c Revision 1.12, Mon Sep 16 13:27:14 2019 UTC "Change menu key bindings to Up and Down and also close it on any mouse press if opened by key." Left/Right pane navigation still working as expected. Please also note that the manpage still displays old default binding: Up, Down Left, Right Change to the pane above, below, to the left, or to the right of the current pane. How-To-Repeat: snapshots 16th September - run tmux - split window in pane left/right/up/down then try to navigate with ctrl-b UP/DOWN you get a menu instead Thanks. Regards, -- clematis (0x7e96fd2400fe7b59)
