Slashdot Mirror
Debian 9 (Stretch) Will Be Released Today (twitter.com)
The Debian Project has been liveblogging today's release of Debian 9 (Stretch) using the Twitter hashtag #releasingstretch. Some of the announcements:
- The oldstable suite (wheezy) has now been renamed to oldoldstable
- Debian jessie now been renamed to oldstable!
- The Debian stretch suites have now been renamed to stable!
- The draft debian-devel-announce post is ready, archive docs are being cleaned up
This release is named after that purple octopus in Toy Story 3, and more tantalizing tidbits of information keep appearing on Debian's micronews site:
- At least 1436 people and 18 teams contributed to Debian in 2017
- Stretch has 25,357 source packages with 9,808,465 source files
- There were 13 different themes proposed to be the official Debian stretch theme
- Debian Stretch ships with the free mathematical software SageMath, you can install it with apt
- During the stretch development, 101 contributors became Debian Developers, and 94 more become Debian Maintainers
- Debian Stretch will ship with the first release of the Debian Astro Pure Blend [for astronomers]
- Debian Popularity Contest gathers anonymous statistics about Debian packages usage from about 195,000 reports
I'm already on Slackware 14.2
Insane!!!!!
How does this affect anyone? Why does this matter? Linux has 2% market share, and Debian is a small fraction of that. Why is this news? Perhaps Slashdot can also post a story about my hello world program that I just wrote in Java. It's about as relevant as this story.
So go use Devuan? Or is the anti systemd crowd now joining the SWJ, Vegan, Crossfitter crowds where they cannot stand silent for 5 minutes before announcing their special needs and wants to the world?
Looks like we're stuck with systemd
No one cares whether you want Debian 9 or not. You are irrelevant and absolutely nobody cares about you. Perhaps instead of whining about Debian 9, if you don't like it, create your own distro that doesn't use systemd. It's open source, so absolutely nothing prevents you from doing that. However, it's far easier for you to whine on an internet forum rather than do something useful. That's exactly why you're irrelevant and why nobody should care what you think. You're just another online hater who likes to tear other people's work down.
Critiquing technology != SJW crybullying
In general systemd is a great improvement, but little things like how the journal tool is not called journal, but instead journalctl and systemd's main program is not called systemd but instead systemctl make it confusing for the ops guys that work for me since they manage about six different UNIX systems. They don't use our Debian servers often enough to remember the obscurely named systemd commands. On the other hand, that's a positive point for Debian since they don't have to touch them very often. Debian just works.
The bigger problem is that messages that used to show on the console with SysV init scripts are now no longer showed on the console, and they are not logged in the journal. That makes troubleshooting a pain in the neck. Simple problems, like a /var/lib/mongodb/mongod.lock hanging around after a power problem which prevents MongoDB from restarting, can take a while to trackdown since nothing logs that error. With Debian before systemd, the init script would show a clear error on the console. A couple of weeks ago after we had an unexpected power outage while swapping out UPS batteries, none of the sixty MongoDB servers we have would restart. My junior guys wasted about four hours before finally giving up and calling me. That was four hours of downtime that we would not have had pre-systemd.
Debian "release engineering" in a nutshell:
The Debian ProjectâVerified account @debian 18m18 minutes ago
If any of the lines in your /etc/apt/sources.list refer to 'stable', you might get a surprise on your next upgrade! #releasingstretch
6 replies 24 retweets 36 likes
They're basically pulling a Microsoft. DO NOT WANT indeed.
Without logs, simple problems can easily turn into major problems. We use Puppet to manage servers and leave SELinux enabled. With Red Hat 6, that wasn't a huge problem since you could almost always see errors on the console or in syslog. With systemd, very often there's no error shown or logged, and you have to know to check /var/log/audit/audit.log. Just checked my main dev machine, and that log file is over 300 MB long, so good luck finding and understanding what you need.
An even bigger problem is that since Puppet is very good at checking exit statuses, like traditional UNIX things, before systemd that was useful. With systemd, "systemctl start [service-name]" almost always returns a zero even though the service doesn't start. The junior guys that run Puppet don't know there's a problem until a customer or a monitoring script complains. That's a huge problem. When we ran Red Hat 6, I'm proud to say that we went over two years without any customer-facing downtime outside of maintenance hours. With Red Hat 7 and systemd, we've had four hours just this month!
I don't understand why systemd always returns zero even when something fails.
Complaining about people complaining. Self aware much?
Just run things by hand. I know that can be hard to get all of the environment variables and command line options correct sometimes, but it's the only option that works since systemd drops log messages.
Puppet isn't great and trying to use it on the unstable foundation of systemd must be hell. I would just give up on that.
That explains the problem with Linux more than anything else. All of the new users I've dealt with in the 24 years I've used Linux were more confused by the different distributions than any other single thing. This has been and looks like it will always be a major problem.
Its ok, you are running MongoDB, which means you already have low (or small if you prefer) expectations.
> systemd is a great improvement
This. The unit files are so much simpler than init scripts! About a year ago, I replaced a 1,200 line shell script with a 17 line unit file, and it works better now. We make a highly-customizable ERP system so shell scripts are a huge problem for us, and since I've been the only one that's good at them for 18 years here, one major reason my life was harder than it should be was because of start-up scripts. systemd made my life easier in that regard.
The problem is that the old shell scripts output errors to stderr so customers could easily communicate the problem to us. Almost always the problems they created were simple things like the wrong owner on a directory or forgetting to run restorecon after mv an old file to a new name and creating a new file so it didn't have the proper SELinux labels. With systemd, stderr is just swallowed and not logged so what used to take us a few minutes to solve with a customer now can take days. Yes, life is better with systemd, but it's not as good as it could be. I don't understand why logging is still broken.
We're getting the infamous "FatalAssertion 34433" with MongoDB on about sixty servers after our SAN went down. The guys working for me didn't know there was a problem since "systemctl start mongod" returns a 0. "systemctl status mongod" returns:
mongod.service - High-performance, schema-free document-oriented database
Loaded: loaded (/usr/lib/systemd/system/mongod.service; enabled; vendor preset: disabled)
Active: failed (Result: start-limit) since Sun 2017-06-18 02:07:39 UTC; 4s ago
Process: 31810 ExecStart=/usr/bin/mongod --config
Main PID: 31694 (code=exited, status=0/SUCCESS)
It failed! Noticed the "Active: failed" line. Why can't systemd return a correct exit status?
You can use a debian derivative without systemd, for example, my favorite...
MX Linux, based on Debian stable
See this
https://mxlinux.org/
and the great forum here
https://forum.mxlinux.org/search.php?search_id=active_topics
A great community, low snark, up to date community repository with the latest and goodies.
Useful MX tools for common tasks.
NO systemd, it uses the older init
That makes two things that brings out the anon trolls in droves: Net neutrality and Systemd.
Anons need not reply. Questions end with a question mark.
This. If "systemctl status" can output the correct state, why can't "systemctl start" also do that?
Complaining shaming is sad.
I comment occasionally so that I can mod others -1 overrated or -1 offtopic.
Lennart is too young to grok UNIX. He just doesn't get why exit statuses are important.
Great examples of the tremendous costs imposed on users by poorly-considered design decisions!
There was a time when professional developers understood that every choice they made either made their system more costly for the user, or less costly. Now, developers are convinced that simply being different - adding costs - is good, and that making customers adjust processes to a new release every few weeks - adding costs - is somehow desirable.
You say that like the other choices of Salt, Ansible, or Chef are much better. They aren't. Plus, they can't work well when systemd swallows log messages and doesn't output a proper exit status.
Even straight guys love em.
My /etc/apt/sources.list points not to stable, but to jessie. I assume most other stable users have their config set the same to avoid exactly the issue you mentioned. 'apt-get update && apt-get dist-upgrade' will not upgrade me to Stretch until I reconfigure my /etc/apt/sources.list.
So basically, you just need to have your config set up properly, and Debian will do what you say.
That's very difficult with something like Tomcat. I wish systemd wouldn't swallow log messages.
Swallowing log messages has made my life shit. I wish systemd would fix their problems.
Complaining shaming is sad.
Complaining is hate speech.
In the free world the media isn't government run; the government is media run.
I don't understand why systemd can't log stderr.
He described specific problems with systemd, that I've also seen, but he was voted down to a -1. How about fixing problems instead of just burying them?
True. Building on a poor foundation makes life hard, but systemd should at least not return a 0 when it doesn't start.
New releases of Debian stable *should* make the front page of Slashdot. It's a proper Big Deal. You can make a huge list of things that Debian stable is not: Not the most used distro, not the most user friendly distro, not the most up to date distro, not the most "libre" distro, etc... But, if you want to find a distro that meets one of those criteria, it's probably based on Debian. When they release a new stable version, the entire open source community benefits.
Here's to decades more of Debian stable!
You say that like the other choices of Salt, Ansible, or Chef are much better. They aren't. Plus, they can't work well when systemd swallows log messages and doesn't output a proper exit status.
Well, there's always Kubernetes
Or return the exit status.
Because Poettering doesn't have enough experience to understand why it is important?
Why I in the f*** does systemd return a zero when a service doesn't start?
Why can't it pass the exit status up to the shell?
Are they late?
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
Because Lennart doesn't understand them?
$ man journalctl
That was easy. Next?
> (Score:-1)
Sad to see the mods here have no respect for people that have actual experience with something. I've had my life made more difficult many more times since upgrading to Red Hat 7 since systemd doesn't log most error messages. Yes, too many Sys V init scripts logged messages to the console so they were lost forever if you weren't watching, but that's better than losing them completely!
Or worse, JBoss. It sucks when it doesn't start and systemd just doesn't log the error.
where is g spot located?
He is young. Give him time.
You people are retarded.
Because Lennart doesn't understand its importance?
Complaining shaming is sad.
Complaining is hate speech.
Labeling something hate speech without first enumerating your privileges is violence.
You should meet my boyfriend. He never swallows!
Same here. My life is shit. I don't understand the decision to just swallow log messages.
Try the butt. No one thinks to look there. Great hiding spot for the g.
The maintainers of systemd don't grok why that is important.
The maintainers of systemd are too inexperienced to understand why that is important.
systemd still sucks though.
Same here. I don't get why they can't log messages.
found it thanks
Here is the solution to the systemd infection.
ftp://linuxmafia.com/kb/Debian...
Another day closer to redwood heaven
You can solve your systemd infection here
ftp://linuxmafia.com/kb/Debian...
Another day closer to redwood heaven
But why can't they pass exit statuses? It's just ridiculous that they don't.
journal tool is not called journal, but instead journalctl and systemd's main program is not called systemd but instead systemctl
That is a major problem for the guys working under me. I wished the systemd guys had picked clearer names.
Looks like it's a child process that returns the non-zero exit code. I would say it's probably a bug in the mongo service file.
The systemd guys obviously don't care about that. Or passing correct exit statuses.
The daemon may exit after it has demonized. Systemctl start has to return at some point.
Exit statuses are critical.
They just don't get why they are important.
Who does that? People who want the upgrade when it arrives. It's not set up like that by default.
> 1,200 line shell script with a 17 line unit file
Why in the hell was this endorsement of systemd voted down?
Too many youngsters now have mod points. They don't understand why exit statuses or syslog is important. The fact that systemd drops stderr and syslog messages makes it just terrible.
No problem.
Why can't it pass the exit status up to the shell?
I have no clue why they can't fix that, but it sucks that systemd doesn't support returning a proper exit status.
So go use Devuan?
I will, the next time I upgrade. (Still using Xubuntu 14.04.)
The other oddity here: I'm a professional astronomer, and I don't see any reason to try Debian Astro Pure Blend. Any astronomy-related software is either packaged for Debian (in which case I've already installed it through apt), or not packaged for Debian (in which case it won't be in Debian Astro either). What's the point of a "Pure Blend" distribution when all you need is a list of package names to feed to apt-get?
Looks like there are many Devuan users/devs around here today...
Tbh, sounds like they're *your* problems.Why don't you fix them, instead of anonymously bitching on the internet?
Because some of us prefer 1,200 lines that work with 17 that don't?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
It are de ways ob they're kind. They hates us.
If you have no understanding of the technical reasons smart people are against systemd and are only seeing it as political opinion or as an acute case of snowflake mutation then I truly hope you are not working in the IT field and suggest you consider joining a SJW group : you would fit perfectly.
And what would those be?
"I know I will be modded down for this": where's the option '-1, Asking for it'?
Because the service doesn't? Really, nothing is a defense against shoddy software, so neither is systemd./p
"I know I will be modded down for this": where's the option '-1, Asking for it'?
I think that it's for users who don't know all those packages to feed to apt and who want to simply install a single meta-package, say "Virtual Observatory" and thus get all the packages included there installed automatically. As I understand it these pure blends is not special versions of Debian either but more working groups that create and maintain these meta-packages that you can install from a vanilla Debian 9.
I see no critiquing, almost every single anti systemd post on Slashdot for the last years have been crybullying. And the GP in particular was crybullying, nothing more.
"systemctl start" schedules the service to start, it does not start it there and then. You might still not like it but systemd is an event driven system and not a "execute this particular bash shell" type of system, so one cannot use systemctl as a straight drop in replacement for how sysv worked, it works differently.
Note that you had this kind of behaviour in some sysv scripts as well so it was more of a hit and miss in sysv. I.e daemons that could take a very long time to start like say MySQL had init scripts that forked and then sysv would return OK when the actual daemon could very well fail a few second later. So with systemd we actually now have a consistent handling and not the old hit and miss but you have to adopt to the new way for the daemons where sysv happened to be "hit"
I guess that the sysv script run pre start tests like checking that lock file and where the ones producting the logs while the systemd unit file for mongodb is just starting mongodb straight up and thus is not getting these particular logs because mongodb does not log about them. Either mongodb should be changed to start logging these things or the systemd unit file should be changed to include those pre start tests that the old sysv script had.
So the problem is not with systemd itself but with the sysv to systemd transition.
Please provide the contents of "/usr/lib/systemd/system/mongod.service" either by cat "/usr/lib/systemd/system/mongod.service" or "systemctl cat mongod.service".
Exactly my thoughts. This is Open Source stuff, they can surely download the source of systemctl then grep the return code in one of those *.c files, then rebuild it on their own. Isn't this the advantage of Open Source Software which the community always brags about? Fixing bugs once they've discovered it.
Complaining shaming is sad.
Complaining is hate speech.
Labeling something hate speech without first enumerating your privileges is violence.
Any communication might cause offense. Therefore all forms of communication must be banned.
In the free world the media isn't government run; the government is media run.
You people are retarded.
Thats hate speech on two levels! Hate speech against me and hate speech against differently abled people!
In the free world the media isn't government run; the government is media run.
It can and does, it just depends on how the distro has set it up.
Does the GNOME version support Wayland?
Use systemd in a production environment and find out. The hard way.
Why I in the f*** does systemd return a zero when a service doesn't start?
Because it's an *asynchronous* start, moron.
You ever heard of CICS? IBM's transaction processing system, used to run critical systems across the world? It has a command, EXEC CICS START, to run a transaction asynchronously. Only a moron would assume that because the START command worked, the transaction it STARTed completed OK. Same here.
Some services take several seconds or minutes or longer to fully start. Do you want systemd to stop dead in its tracks waiting? You'd whinge about that for sure.
Finally, all discussion of Linux on /. is now *dead* due to morons bringing systemd into everthing. Fuck off and die you cunts.
In other words, parotted bullshit, no reasons.
"I know I will be modded down for this": where's the option '-1, Asking for it'?
In other words, parotted bullshit, no reasons.
Yeah, that's mostly what I see. I get that some people don't want a C application running their init system and would rather have shell scripts. That's fine.
I run a couple dozen unique instances with systemd and I don't see the problems that they keep saying are inherent. I can't claim that nobody hits them, but I don't and I enjoy fast/parallel boot times. It's especially useful with complex storage stacks and virtualization when there are multiple levels of dependencies.
The complainers seem to ignore the fact that there are millions of systemd-based systems in production and then claim that they can''t work. Ignoring reality is a great way to get me to tune out really quick.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
the last years have been crybullying
If that's above your threshold for bullying then oh boy are you a sensitive little snowflake.
SJW n. One who posts facts.
And what would those be?
Very hard to debug problems, for one. For example, on this here very laptop, after I unplug it from the power it cleanly shuts itself down after a period of maybe 20 to 30 minutes. It's not running the upower daemon, and everything related to battery level is set to 0.
There's nothing in the log indicating why it's shutting down or where the shutdown command is coming from. So far, no one has ever suggested a new place to look or a new avenue to try---well excepting one guy who said "it's your window manager moron", though he went silent of course when I pointed out my window manager is FVWM.
I've never had an undebuggable problem on the older boot systems.
SJW n. One who posts facts.
Read all the posts from AC:s regarding systemd to this article and tell me how you can come to a different conclusion. There are tons of "Poettering don't know about exit codes", "systemd eats logs" and so forth. None of them are true and all of them are crybullying.
Nary a peep about this:
Ah, where are the flame wars of yesteryear?
I guess Mozilla has moved on to new frontiers in alienating the open source community.
Complaining shaming is sad.
Complaining is hate speech.
Labeling something hate speech without first enumerating your privileges is violence.
Any communication might cause offense. Therefore all forms of communication must be banned.
Agreed! All communications shall be banned henceforth. While we're at it shall we also agree that bans be banned (expect for this ban banning bans)? I'll take your non-response (due to the communication ban) as confirmation!
almost every single anti systemd post on Slashdot for the last years have been crybullying.
tmpfiles: R! /dir/.* destroys root
poettering commented on Mar 30: I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf /foo/.*" will work the exact same way, no?
Again:
Bug Security IT Linux /" Is Now Bricking Linux Systems (phoronix.com) 699
Running "rm -rf
Posted by timothy on Monday February 01, 2016 @08:56AM from the now-you-can-troll-harder dept.
An anonymous reader writes:
For newer systems utilizing UEFI, running rm -rf / is enough to permanently brick your system. While it's a trivial command to run on Linux systems, Windows and other operating systems are also prone to this issue when using UEFI. The problem comes down to UEFI variables being mounted with read/write permissions and when recursively deleting everything, the UEFI variables get wiped too. Systemd developers have rejected mounting the EFI variables as read-only, since there are valid use-cases for writing to them. Mounting them read-only can also break other applications, so for now there is no good solution to avoid potentially bricking your system, but kernel developers are investigating the issue.
tmpfiles: R! /dir/.* destroys root #5644
poettering commented on Mar 30: I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf /foo/.*" will work the exact same way, no?
Is he wrong?
I don't see you refuting Lennart's argument, actually. He is right: Unix gives you the rope to hang yourself with, and a faulty directive in a systemd unit is as bad as a typo in a shell command (or a SysV startup script).
"I know I will be modded down for this": where's the option '-1, Asking for it'?
So, you're a paying customer of the strongest commercial backer of systemd? Did you let them know about this? Did you complain about losses and asked for explanation on plans to correct the problems, in order to decide on your way forward, including whether or not to stay on their solution?
Because that is the only meaningful way of influencing their decisions. If customers are angry, then s..t like this either gets fixed or rolled back (note - you don't get to choose the option, they do; you should only care if it works or not). If not, then it's business as usual.
Just ignore the fact that it was fixed on Mar 27, 3 days before that Poettering quote. Yes he was wrong, I never said that he was infallible. That people still bring this issue up as "systemd is bad" is part of the crybullying yes, or are we now pretending that "rm" is completely fucked up because it once had the same bug (Poetterings fault was of course that he believed that rm still had that particular bug)? I don't think so.
Almost everyone who runs a production GNU/Linux system in 2017 runs systemd. If it were even 1% as bad as the systemd trolls claim, GNU/Linux on the server would be radically losing marketshare to FreeBSD and even Windows. It isn't.
You are not alone. This is not normal. None of this is normal.
He is right:
Try it. He's not. That has never worked that way. Unix is smart enough to cut the rope for you if you try to hang yourself with that.
root@m6700:/tmp# ls -lah .. .Hello .World /tmp/.* ..
total 8.0K
drwxrwxrwt 2 root root 4.0K Jun 18 22:12 .
drwxr-xr-x 21 root root 4.0K Jun 18 22:12
root@m6700:/tmp# touch
root@m6700:/tmp# mkdir
root@m6700:/tmp# rm -rf
rm: refusing to remove '.' or '..' directory: skipping '/tmp/.'
rm: refusing to remove '.' or '..' directory: skipping '/tmp/..'
root@m6700:/tmp# ls -lah
total 8.0K
drwxrwxrwt 2 root root 4.0K Jun 18 22:14 .
drwxr-xr-x 21 root root 4.0K Jun 18 22:12
Why is it not called systemschedule then if it controls only a scheduler and not the system?
Ad populum works on the corporate managers, not the nerds.
Why would you keep those 17 lines that don't work in your 1200-line script?
Just comment them out!
If indeed it was just 17 lines of code that didn't work they might have a point. It's not so hard to fix 17 lines of code. In fact the reason we like 1200 lines of code is because we can fix it.
The reason we don't like those 17 lines of code is they are really 1,139,536 lines of code hiding behind 17 lines of configuration. Worse it's not just 1 million lines of simple C, but multiple processes communicating through a horrid RPC system that makes the entire thing utterly opaque.
I didn't think there could be anything that could make me pine for the days I could fix a problem just debugging 1200 written in one of the worst programming languages on the planet (shell script) - but bless his black little heart, Lennart has managed to prove to me I was wrong.
Sigh. Whining about a technicality in an example may make you feel like you're smart, to the rest of the world you're just a dick.
"I know I will be modded down for this": where's the option '-1, Asking for it'?
I just recently upgraded to Jessie
I have no problem with SystemD and use it at home and on some production systems.
However, there are a huge number of Red Hat using companies who are sticking with RH 6 because of systemd. Most of them will eventually go to RH 7 and systemd, but until 2020, RH will continue to support their pre-systemd Enterprise release.
Cheap storage VM.
SystemD was designed assuming the happy path. Kind of like what you get from a freshman CS student. When crap hits the fan, the failure modes are largely undefined. There's also the difficult to port aspect, which is a bad thing for these kinds of projects that typically lend themselves well to porting. And some repetition and inconsistencies. SystemD is the PHP init systems. I know it's not just init, but that's what it's known for. At one point there was an open bug that got closed as "working as intended". The person who submitted it got lambasted by the primary dev for thinking the logs getting corrupted by an unexpected shutdown was a bug. Of course it's a feature! Why would you ever expect your logs to be in working order when you machine crashes? Ohh.. maybe to try to figure out why it crashed.
The whole project reeks of of NIH syndrome. It was created for a good reason, and the concept is great, but the implementation is left wanting in design and has a tenancy to keep swallowing up other projects. Why does SystemD need a DHCP server built into it, an NTP client, a NAT?! Because they can, I guess.
SystemD: Why do one thing well when you can do everything half-assed?
find /tmp/.* -delete
will happily remove / too. Is it a find bug? Nope. . and .. do match .* glob. An application may provide a safeguard, but it's not *required* to do so.
1200 lines of shell script invoke a shitload of utilities written in C. So if you decide to go deeper with systemd, you should also count and sum LoC of all utils which are called from your scripts.
I see lots of unfounded assertions. I am not impressed.
"I know I will be modded down for this": where's the option '-1, Asking for it'?
So your argument went from: "He's Right" to "You're a dick for pointing out he's not right".
Because he was NOT right. Not only was he not right he was completely wrong. I discovered that 'feature' way back when I was learning UNIX on OS X 10.0.
How does the person that wrote the next gen init glob not know that?
Subjective opinions aside, the fact that the lead dev gave someone a tongue lashing over expecting his logs to be at-least partially usable after a system crash so he could figure out why it crashed, is absurd. His recommendation was to expect no logs to be viable and just throw them out. This was after it was already in CentOS stable as the default.
I have never seen a system that corrupted all of the log data from an unexpected shutdown, only possibly the last little bit or the FS taking a crap, but that's orthogonal to the discussion. I wish I kept the link, but this was all on SystemD's official bug tracker. My opinion is warranted to think that SystemD is a "happy path" kind of design.
I have. Since we now have competing anecdotes, how about some actual arguments for a change?
Oh no, all you do is parrot talking points. Here's a cracker, Polly.
"I know I will be modded down for this": where's the option '-1, Asking for it'?
Because no one wants to have that long command names on Unix? All the new init systems like systemd, upstart and smf are event driven. With sysv as I said you only have hit and miss and people using the exit code from the sysv scripts have just been lucky that it's worked somewhat for them combined with the fact that some of the old sysv scripts contained pre flight checks that the people who ported them to systemd unit files forgot to add.
It's better. Still a quarky setup.. like asking about where to put grub when it knows damn well where. As if it even gives us a choice. Side from the installation that IMHO is overdue to be updated, it seems to be a bit better. I see no reason to switch to it from Fedora 25 with KDE, however. Probably just my preference.
# find /tmp/.* -delete .* glob matches both . and .. -- so find has all rights to delete them. It could have implemented a safeguard to disallow this, but it's not required to do so. The same goes for systemd.
will happily remove your root, too. Does it mean that find is buggy? -- nope.
rm doesn't allow . and .. removal because such behavior is required by POSIX.
> If indeed it was just 17 lines of code that didn't work they might have a point. It's not so hard to fix 17 lines of code. In fact the reason we like 1200 lines of code is because we can fix it.
>
> The reason we don't like those 17 lines of code is they are really 1,139,536 lines of code hiding behind 17 lines of configuration.
1200 lines of shell code run a lot of external utilities for almost anything. These utilities are mostly written in C. Furthermore, the shell which runs these 1200 LoC is written in C, too. So if you decide to count systemd's lines of code, you should really count LoC of your shell and all utilities it runs, too.
And if you ask me, I'd prefer fixing relatively simple systemd rather than Turing-complete complex shell.
"Do you want systemd to stop dead in its tracks waiting?"
Like it in fact does at startup (network unavailable, two minutes), or like it in fact does when trying to shut down (unknown reason, two minutes)?
Maybe instead it should have a PENDING result code.
Done. Most of us have no issue with it in a production environment. Try again.
Better a parrot than an astroturfing apologetic shill that doesn't understand the difference between the filesystem corrupting log data or the logger corrupting log data.Then again, "Arguing on the internet is like running at the special olympics...". Sometimes giving up is the correct response.
What, never? Never worked that way? Are you sure?
Watch this Heartland Institute video
the fact that the lead dev gave someone a tongue lashing over expecting his logs to be at-least partially usable after a system crash
Amusing anecdote. Pity it's not true.
Watch this Heartland Institute video
The bigger problem is that messages that used to show on the console with SysV init scripts are now no longer showed on the console, and they are not logged in the journal. That makes troubleshooting a pain in the neck. Simple problems, like a /var/lib/mongodb/mongod.lock hanging around after a power problem which prevents MongoDB from restarting, can take a while to trackdown since nothing logs that error
Repost of trolling from over a year ago.
Watch this Heartland Institute video