El 22/10/22 a las 15:56, Paul Leiber escribió: > On Wed, 29 Jun 2022 15:03:31 +0200 =?UTF-8?B?RnLDqWTDqXJpYyBNQVNTT1Q=?= > <[email protected]> wrote: > > Hi, > > > > I have a local server that uses Debian testing. I updated the server, it > > went from a kernel 5.17 to 5.18. After the reboot, the network was no > > longer active. The network interfaces were down. > > > > In the logs I had these error messages: > > > > systemd-udevd[396]: 0000:01:00.0: Worker [425] processing SEQNUM=2140 is > > taking a long time > > systemd[1]: systemd-udev-settle.service: Main process exited, > > code=exited, status=1/FAILURE > > systemd[1]: systemd-udev-settle.service: Failed with result 'exit-code'. > > systemd[1]: Failed to start Wait for udev To Complete Device > Initialization. > > systemd[1]: systemd-udev-settle.service: Consumed 4.055s CPU time. > > [...] > > systemd[1]: ifupdown-pre.service: Main process exited, code=exited, > > status=1/FAILURE > > systemd[1]: ifupdown-pre.service: Failed with result 'exit-code'. > > systemd[1]: Failed to start Helper to synchronize boot up for ifupdown. > > systemd[1]: Dependency failed for Raise network interfaces. > > systemd[1]: networking.service: Job networking.service/start failed with > > result 'dependency'. > > ithaqua systemd[1]: ifupdown-pre.service: Consumed 3.807s CPU time. > > > > > > I found this bug report and replaced the line > > "Requires=ifupdown-pre.service" with "Wants=ifupdown-pre.service" in > > "/lib/systemd/system/networking.service". > > > > During boot there is a delay, but the network interfaces were up and the > > network is active. > > > > > > Regards. > > -- > > ============================================== > > | FRÉDÉRIC MASSOT | > > | http://www.juliana-multimedia.com | > > | mailto:[email protected] | > > | +33.(0)2.97.54.77.94 +33.(0)6.67.19.95.69 | > > ===========================Debian=GNU/Linux=== > > > > > > I have the same issue as described by Frédéric in an up-to-date Debian > Bullseye 11.5, kernel 5.10.0-19-amd64. Manually starting the network via > ifconfig works. The workaround described by Ron mitigates the error. > However, the delay during boot exists also in my system. > > Paul >
Sorry for the delay to answer on this.
For the moment, it seems replacing the dependency for Wants seems to be
the more suitable solution. Also, from systemd.unit(5):
Wants= … This is the recommended way to hook the start-up of one
unit to the start-up of another unit.
Requires= … Often, it is a better choice to use Wants= instead of
Requires= in order to achieve a system that is more robust when
dealing with failing services.
Happy to learn if there would be a better fix.
Cheers,
-- Santiago
signature.asc
Description: PGP signature
