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.
Mark Haney wrote:> 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. >Yup. I have issues with just trying to find out the name of a service to restart.... But let's not go on about it. I just had a throwaway, and really didn't intend to start something like the last flame thread on systemd, that went on for weeks.... mark
On Wed, Jun 07, 2017 at 11:31:06AM -0400, Mark Haney wrote:> 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/.Now this is just silly. It didn't "blow itself up". Nothing blew up at all. There are just messages logged. There is no actual problem. -- Matthew Miller <mattdm at fedoraproject.org> Fedora Project Leader
On Jun 7, 2017, at 9:31 AM, Mark Haney <mark.haney at neonova.net> wrote:> > 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?m sure James Hogarth meant that circular symlink chains are a problem for any program, not just for systemd. Now if you can show that systemd *generated* this chain, you might have a point. Since we have only one report of this, it seems unlikely that systemd is doing this. Surely we?d have thousands of reports of this is something systemd always did.> I have never seen init.d blow itself up over bloody symlinks.Only the systemd-readahead process failed. It?s an optional component. systemd is clearly not ?blown up? on Mark?s system, else he couldn?t have gotten to a login prompt. This optional component diagnosed an actual problem, that?s all.> The readahead, while /possibly/ nice isn't at all necessary on modern hardware.Explain then why a VM containing a given OS generally boots faster the second time on a given host than rebooting the same OS on the bare hardware running that VM host. RAM caches matter more today than they ever did, due to the vast disparity between storage access speeds in a modern system. Precharging the caches is still a good idea in 2017.> I want my hardware to boot consistently, not bomb like an Adam Sandler movie because of /symlinks/.Hyperbolic much?> I'd be willing to bet a year's salary most admins hate systemd with a passion.I think you?re basing that bet on data generated by an angry noisy minority.
On Wed, June 7, 2017 10:43 am, Warren Young wrote:> On Jun 7, 2017, at 9:31 AM, Mark Haney <mark.haney at neonova.net> wrote: >> >> 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???m sure James Hogarth meant that circular symlink chains are a problem > for any program, not just for systemd. > > Now if you can show that systemd *generated* this chain, you might have a > point. > > Since we have only one report of this, it seems unlikely that systemd is > doing this. Surely we???d have thousands of reports of this is something > systemd always did. > >> I have never seen init.d blow itself up over bloody symlinks. > > Only the systemd-readahead process failed. It???s an optional component. > systemd is clearly not ???blown up??? on Mark???s system, else he > couldn???t have gotten to a login prompt. > > This optional component diagnosed an actual problem, that???s all. > >> The readahead, while /possibly/ nice isn't at all necessary on modern >> hardware. > > Explain then why a VM containing a given OS generally boots faster the > second time on a given host than rebooting the same OS on the bare > hardware running that VM host. > > RAM caches matter more today than they ever did, due to the vast disparity > between storage access speeds in a modern system. Precharging the caches > is still a good idea in 2017. > >> I want my hardware to boot consistently, not bomb like an Adam Sandler >> movie because of /symlinks/. > > Hyperbolic much? > >> I'd be willing to bet a year's salary most admins hate systemd with a >> passion. > > I think you???re basing that bet on data generated by an angry noisy > minority.With all my respect to Warren, I still decided to mention: noisy minority are the only ones everyone hears. There is big bunch of people who stopped saying anything as when one does, he gets in the middle of heated argument, gets shushed upon... And both sides of argument do realize that arguing will not change anything. Especially NOT on CentOS list. I am just mentioning that obviously visible minority has a bunch of invisible folks agreeing with them who decided to stop commenting on this, and some who fled elsewhere (and definitely didn't change their minds). Sigh. Let's close this theme, and go back to administering systems we love (whichever OS that would mean for you). Valeri ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++