Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#34760 - [ypbind-mt] ypbind.service should have -no-dbus set by default

Attached to Project: Arch Linux
Opened by Brian BIdulock (bidulock) - Saturday, 13 April 2013, 00:07 GMT
Last edited by Tom Gundersen (tomegun) - Thursday, 16 May 2013, 00:51 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Tom Gundersen (tomegun)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

ypbind-mt checks to see if networkmanager reports the network online before starting. If networkmanager is running and does not report the network online, ypbind hangs.

NetworkManager can easily be configured to unmanage ethernet devices, in which case it reports the network offline even when it is online. It is systemd's job to determine the order of startup, not ypbind's. The default yobind.service file should include the -no-dbus option by default so that ypbind will not hang the boot process.

Additional info:
* package version(s) ALL

Steps to reproduce:

configure networkmanager in the keyfile to not manage any ethernet macs

set ypbind to bind to any domain and enable it

reboot
This task depends upon

Closed by  Tom Gundersen (tomegun)
Thursday, 16 May 2013, 00:51 GMT
Reason for closing:  Implemented
Comment by Brian BIdulock (bidulock) - Saturday, 13 April 2013, 00:08 GMT
Gosh, better still, compile it without dbus support: remove --enable-dbus from PKGBUILD.
Comment by Tom Gundersen (tomegun) - Saturday, 13 April 2013, 00:24 GMT
Hm, systemd currently does not track the network state, so if ypbind really must be started after the network is up, adding -no-dbus would break things. The proper fix sounds like teaching ypbind to deal with being started before the network is ready. Maybe upstream has some input on this?
Comment by Brian BIdulock (bidulock) - Saturday, 13 April 2013, 00:40 GMT
No, ypbind starts fine before the network is up. It just keeps trying util it can get a response. Also, systemd has a network.target upon which ypbind depends.

It is really related to the other problem. It is an attempt to keep systemd or sysvinit for that matter, from proceeding before ypbind has a chance to bind.

With systemd the ultimate would be to sd_notify() on the first bind to a server. For sysvinit the best would be to stall the parent thread exiting before the first bind. This is how ypbind (no -mt) use to work.
Comment by Tom Gundersen (tomegun) - Saturday, 13 April 2013, 00:46 GMT
Great. If that's how it works, then once sd_notify() works correctly we should drop all the interactions with NetworkManager, and also drop the dependency on network.target.

Btw, it would be really great if upstream would ship the correct systemd unit files (in case you were going to write a patch ;-) ).

Loading...