Matthew Miller wrote:> On Wed, Jun 07, 2017 at 10:10:14AM -0400, m.roth at 5-cent.us wrote: >> I just updated a system - as in minutes ago, and log back in after it >> reboots, and this is in dmesg: >> [ 88.202272] systemd-readahead[484]: >> open(/var/tmp/dracut.fP4yj1/initramfs/usr/bin/loginctl) failed: Too many >> levels of symbolic links >> [ 88.202515] systemd-readahead[484]: >> open(/var/tmp/dracut.fP4yj1/initramfs/usr/lib/systemd/system/dracut-emergency.service) >> failed: Too many levels of symbolic links >> Anyone know what this is - some weird bug, a garbage message? > > systemd-readahead is just trying to pre-cache stuff into memory so boot > time is faster. I'm not sure eaxctly what's going on here but that > message is typical of having a loop in your symbolic links (which can > easily happen with relative links). > > I'm not quite sure what *exactly* is going on, but it looks like maybe > dracut temp files didn't get cleaned up properly and that they contain > such a loop. I bet you can just rm -rf /var/tmp/dracut.fP4yj1. >Thanks for the info. Now, why it shouldn't have cleaned itself up when I gave it the reboot command... I see too many (that's defined as more than zero) cases where systemd WANTS TO BOOT FAST, and doesn't wait for things to finish - sush as not getting the hostname from dhcp, and so having to hardcode the name instead. Systemd, as I've said before, seems to be targeted towards laptops. Not servers. Not workstations. *bleah* mark
On 7 June 2017 at 16:13, <m.roth at 5-cent.us> wrote:> Matthew Miller wrote: >> On Wed, Jun 07, 2017 at 10:10:14AM -0400, m.roth at 5-cent.us wrote: >>> I just updated a system - as in minutes ago, and log back in after it >>> reboots, and this is in dmesg: >>> [ 88.202272] systemd-readahead[484]: >>> open(/var/tmp/dracut.fP4yj1/initramfs/usr/bin/loginctl) failed: Too many >>> levels of symbolic links >>> [ 88.202515] systemd-readahead[484]: >>> open(/var/tmp/dracut.fP4yj1/initramfs/usr/lib/systemd/system/dracut-emergency.service) >>> failed: Too many levels of symbolic links >>> Anyone know what this is - some weird bug, a garbage message? >> >> systemd-readahead is just trying to pre-cache stuff into memory so boot >> time is faster. I'm not sure eaxctly what's going on here but that >> message is typical of having a loop in your symbolic links (which can >> easily happen with relative links). >> >> I'm not quite sure what *exactly* is going on, but it looks like maybe >> dracut temp files didn't get cleaned up properly and that they contain >> such a loop. I bet you can just rm -rf /var/tmp/dracut.fP4yj1. >> > Thanks for the info. Now, why it shouldn't have cleaned itself up when I > gave it the reboot command... I see too many (that's defined as more than > zero) cases where systemd WANTS TO BOOT FAST, and doesn't wait for things > to finish - sush as not getting the hostname from dhcp, and so having to > hardcode the name instead. > > Systemd, as I've said before, seems to be targeted towards laptops. Not > servers. Not workstations. *bleah* >Mark stop with the flame baiting please. This is nothing systemd specific - and keep in mind /var/tmp is a persistent temp area unlike /tmp which as it's tmpfs by default is of course emptie don boot.
> Thanks for the info. Now, why it shouldn't have cleaned itself up when I > gave it the reboot command... I see too many (that's defined as more than > zero) cases where systemd WANTS TO BOOT FAST, and doesn't wait for things > to finish - sush as not getting the hostname from dhcp, and so having to > hardcode the name instead. > > Systemd, as I've said before, seems to be targeted towards laptops. Not > servers. Not workstations. *bleah*I'm still thinking it's a jacked up filesystem. I'm not sure what fs you're using, though the default is xfs, but I'd look at dmesg and boot.log to see if the kernel is finding issues with the drives or just the fs. It's also possible that server had been up a long time and RAM was funky. I've seen both of these happen before. As far as using systemd based systems on servers, a month or so back, I pushed a new C7 kickstart for servers we send to customers and haven't seen anything to make me think systemd isn't good for servers. That doesn't mean it's not a giant POS for administrators. If only they hadn't jacked the syntax all to hell from initd, I might be slightly happier with it. That by itself has to be the most ridiculous thing any group of devs have ever done. And for no rational reason either. </endrant>
Mark Haney wrote:> >> Thanks for the info. Now, why it shouldn't have cleaned itself up when I >> gave it the reboot command... I see too many (that's defined as more >> than zero) cases where systemd WANTS TO BOOT FAST, and doesn't wait for >> things to finish - sush as not getting the hostname from dhcp, and sohaving to>> hardcode the name instead. >> >> Systemd, as I've said before, seems to be targeted towards laptops. Not >> servers. Not workstations. *bleah*> I'm still thinking it's a jacked up filesystem. I'm not sure what fs > you're using, though the default is xfs, but I'd look at dmesg and > boot.log to see if the kernel is finding issues with the drives or just > the fs. It's also possible that server had been up a long time and RAM > was funky. I've seen both of these happen before.Not sure what you mean when you say "jacked up filesystem". Here's fstab: UUID=b32212c1-bb97-4a99-8200-aa8152da528d / xfs defaults 0 0 UUID=d6648305-f049-4d7d-9999-670979da3cbe /boot xfs defaults 0 0 UUID=1bc3baaf-4b52-4309-9564-f80f2c098643 swap swap defaults 0 0 LABEL=export1 /export/1 ext4 defaults 0 0 mark
On 06/07/2017 11:24 AM, James Hogarth wrote:> > Mark stop with the flame baiting please. > > This is nothing systemd specific - and keep in mind /var/tmp is a > persistent temp area unlike /tmp which as it's tmpfs by default is of > course emptie don boot.I would wholeheartedly disagree. This IS something systemd specific. I have never seen init.d blow itself up over bloody symlinks. The readahead, while /possibly/ nice isn't at all necessary on modern hardware. I want my hardware to boot consistently, not bomb like an Adam Sandler movie because of /symlinks/. But hey, call it flamebait if you want. I'd be willing to bet a year's salary most admins hate systemd with a passion.