Everything to come out of freedesktop.org for the last year or two is like that. That's why just about every major software they produce has been forked except for pulseaudio (which is best just removed from the system).
I have actually looked at it and it is a massive pile of excrement. Just look at that dizzying pile of config files with non-descript names. Just look at how it auto-generates even more at boot time based on templates. That is supposed to be better?
It makes simple things obscure. It looks like it is actually easier to rip it out and put sysV back than it is to solve even the simplest issues.
Don't worry, there will be plenty of those. Here's one:
I am testing Jessie with systemd and find that systemd absolutely refuses to mount a btrfs filesystem in degraded mode even though I explicitly set the option in fstab.
Can anyone tell me how to either force it to at least attempt mounting or to have it leave fstab alone and call my script to do the mounting?
No, dropping to an emergency shell so I can mount it manually over IPMI is not an acceptable alternative.
Basically, systemd requires manual intervention to allow to boot btrfs arrays with both/a missing disk/ and in/degraded mode/
Not a bad default really.
But it's a terrible ONLY choice. I specified that degraded mode should be used if necessary, systemd ignored my setting.
Anyway, in order to allow btrfs to automatically boot in degraded mode with missing disks, and doing it/correctly/ you need some extra module/script/daemon to handle it, since neither the kernel nor systemd (udev) have any knowledge about the internal state of btrfs.
I WISH it had no knowledge. It apparently had enough to figure out that a disk was missing, but not enough to notice that I said mount anyway.
Nothing new in that, raid etc. have always been handled by such a daemon. I think that if you use mdadm with btrfs raid, you can automatically mount degraded mode arrays.
If I use mdadm with btrfs, I'm defeating much of the point of btrfs. Btrfs 'raid' is not literally a raid, it is similar but more flexible. But as for the actual md in Linux, the daemon is optional. mdadm is used to probe for and start the raid volumes, but from there it's up to the driver. You CAN run mdadm in monitor mode as a daemon if you like (and it is a good idea).
If you read the above discussions, you will find that there is no right solution for all; doing brute force attempts to mount missing drives or bring up raid arrays even though they may not be complete yet (a late drive will make the array degraded) have its own sets of problems, and differs whether it is a two drive or a 1024 drive array.
It has been working fine for over a decade now without systemd. In general for small volumes, if one drive hasn't managed to get ready by the time you're mounting filesystems, it is failing and needs to be kicked out of the array anyway. Mdadm can and WILL bring a raid up in degraded mode if at all possible. If you also run mdadm as a monitor, it will email you promptly about the degraded array.
Remember, RAID isn't just a way to make your data survive a drive failure, it is about high availability. A highly available system cannot panic at the slightest hint of trouble.
Also, it is not up to either systemd or udev to know about complicated raid states; that should be handled by the raid array software/daemon who can probe internal logic and then inform init what to do (or rely on crude timers).
Yes, yes, 1000 times YES! So why does it butt in and refuse to try mounting based on it's examination of what drives are part of the filesystem (internal state anyone)? Shouldn't it butt out and just issue the mount command and let the filesystem work it out? (or report failuer and so try again after the countdown)
Arrays come up R/W and degraded all the time. It's part of being highly available. If it's important enough, there's usually a hot spare and the array will begin rebuilding immediately. Btrfs may grow that feature one day, but until then, I might well have a cron job check on it and see if it needs a spare added (and run balance, of course)
As for all that about writing wrappers and daemons and such, isn't systemd supposed to be simple? That sounds like a lot of hoops to jump through just to get it to not do something obnoxious that it shouldn't be doing. I'm not wanting to do something odd here.
Hypothetically, my production box needs this fixed pronto. No time to wait for the committee to debate if this is WontFix or not. So, it sounds like my best bet is to tell systemd to ignore fstab entirely and run my scripot (borrowed from sysV) instead. What's the procedure for that?
That people use a rather cartoonish interpretation of what Unix Philosophy is to attack systemd, is another matter. That everything should be small single-function programs piped together with a text-only interface, simply isn't the case for the vast majority of Linux and Unix programs. It is a design ideal that no one really follows for anything remotely complicated. Even Vim isn't correctly designed by this cartoonish interpretation of Unix Philosophy.
It absolutely is true for system utilities (like init). Vim is a text editor. It edits text. It does not edit graphics, init the system, act as a login daemon or multiplex your shell. But then, it's not a system utility. Look at awk, sed, grep, less, etc etc. Look at getty and login. Look at screen.
Did you know that in Debian Wheezy there are TWO init systems that work at the same time? They weren't designed to do that but because they do things the Unix way, they don't 'mind' either.
But here's a "funny" where systemd is most definitely wrong (yes, I have actually been giving it a chance, I just don't like what I see). I have a VM where I have yanked a virtual disk out from under btrfs. My fstab states that I want it to mount in degraded state if necessary (such as if a disk is missing). systemd *REFUSES* even though I explicitly commanded the action. How is that the Unix way? How is that supposed to help uptime? Thank the gods it's not a production box! Then I google as to why that might be and first post I find is some someone claiming IT'S A FEATURE! So there we are, the admin and owner of the box says just do it and damn the consequences and it refuses like a Windows box.
Now, just to complete the picture, do you know what journalctl told me about what was failing and why? It said the mount timed out. THAT IS ALL. Is this the system I am supposed to trust in production? The one designed by people who KNOW what they're doing?
Digging in to it, I find the really sad part. It knows enough about btrfs to dig in to it and discover what physical drives go with the volume label. It wasn't even attempting the mount command fstab suggested (if it had, it would have succeeded). Surely after sitting in the penalty box for a minute and a half staring at the cylon, it could have given it a try?!? Or known a bit more about btrfs and seen that I intended a degraded mount? Or known less about btrfs and just done what fstab said to do?!?
Perhaps. I suspect that the reason why such a feature never was developed was the usual catch 22: such a feature would change how init worked, making it incompatible with other init systems. Since no one could lead such a change, everything remained the same.
Actually, it would not. Why not a program that grabs the requested ports and other resources that require root, then drop privileges and pass them on to the daemon. It would drop right in to any sane init out there. It could even be used on a case by case basis. Launch apache with it but not postgres, etc.
Nothing prevents other Unix like systems in implementing similar features.
You seem pretty generous with OTHER PEOPLE's time. I'm fairly sure *BSD will never in a zillion years let systemd anywhere near their OS. They shouldn't! I'm also pretty sure a lot of daemon developers aren't going to sacrifice portability at the alter of systemd. If systemd wasn't such a tangle of dependencies, someone MIGHT implement limited bits of it in other OSes but if you hand them all or nothing, it's going to be nothing. Especially since systemd depends on a linux kernel only feature or 3.
Beauty is of course in the eye of the beholder, but perhaps your perception of systemd isn't without prejudice; many of the core systemd developers a really experienced Linux developers with deep expert knowledge about various aspects of low level system design.
Appeal to authority isn't a very good argument. Many really experienced developers with a deep expert knowledge about various aspects of low level system design think the design of systemd is crap. Many others consider it too immature for primetime.
Lennart Poettering has demonstrated through his designs that he does NOT understand the "Unix philosophy". If he did, the new init system would raise little controversy and would play much nicer with others.
No troll here. Just someone who apparently is a lot more likely to write that paper one day than you are. If you think I'm talking gibberish, it's because the argument is over your head. Had you been more polite about it, I might be more polite here.
Actually, systemd keeps all of that complexity and more, it just sweeps it under the rug and makes it into a single point of failure.
Also, unless the daemon decides it wants to give up all portability and lock itself into systemd, it has to implement all of that code anyway and ignore systemd. Or worse, it can add yet another compatibility shim and accommodate systemd as well.
Of course, a SIMPLE utility could do that job on a case by case basis and be usable by systemd or sysvinit or openrc, etc etc. It could also be portable to *BSD and OSX (unlike systemd). Systemd's 'design' reminds me of Robin Williams talking about God getting incredibly stoned and creating the platypus.
As a bonus, that approach wouldn't screw up a simple thing like fstab.
Meanwhile, where are these experts and those amazing code reviews?
And so I claimed that it actually is a good language to use, not just there by inertia.
In what way is Jit going to run faster than a binary pre-compiled after careful (and automated) profiling and tuning? JIT's advantage is in cases where the end user can't do a custom compile.
Trying to make a virtue out that of the fact that SysVinit is so crude and broken it exposes userland to potential data corruption is just plain denial.
No, it's just a healthy understanding of the KISS principle. There is a virtue to something too simple to screw up.
No JIT will be as fast as compiling once in advance for exactly the hardware it will run on. Especially given the chance to do time (and correctness) trials with various optimizations first. Interestingly, JIT and scripted languages make a lot more sense for small to medium clusters, particularly if they would see idle time anyway. In those, the pressure to get value from every cycle tends to be a bit lower such that saving development time and debugging effort may be worth it.
Pull your head out of the sand. The system did not come up far enough to do what you suggest even though it was clearly capable of it (since it did when sysvinit was in place).
What special treatment? Are you now claiming it is somehow going the extra mile for an ISP to actually do the bare minimum they already promised to do?
FORTRAN is an excellent language for that sort of thing even though the standards people seem hell bent on screwing that up lately.
C is great for many things but it's too easy to have bugs that crash it in hard to diagnose ways. Interpreted languages have their place too, but not when absolutely maximum performance is a requirement.
You're forgetting, the last time those very same telcos engaged in mass law-breaking on the behalf of the NSA, they got blanket immunity as a reward. Those who didn't cooperate got contracts terminated and a 'coincidental' string of denials on the regulatory front.
It may be dirty and crooked but not stupid to go ahead and do the MITM attack secure in the knowledge that at the end of the day their customers will be forced to eat the losses and have nowhere else to go for their telecommunications if anything goes bad.
You only get spanked if you don't cut the NSA in on the haul. That is NOT paranoia, it's a summary of recent history.
Moreover, the only way they could even do it would be to install trusted certificates on the phones that they sell. How long do you suppose that would fly under the radar before being discovered? Do you really think Google or Apple would go along with it? Use some common sense man....
The telcos have considerable latitude with the extra crap they bundle onto the phones. Do you really think Apple would rather not sell iFruits in the U.S. than agree to allow a few mandatory extras from the telcos?
Slashdot Mirror
It sounds like his decision to make on the behalf of his employer.
Everything to come out of freedesktop.org for the last year or two is like that. That's why just about every major software they produce has been forked except for pulseaudio (which is best just removed from the system).
Evidence?
I have actually looked at it and it is a massive pile of excrement. Just look at that dizzying pile of config files with non-descript names. Just look at how it auto-generates even more at boot time based on templates. That is supposed to be better?
It makes simple things obscure. It looks like it is actually easier to rip it out and put sysV back than it is to solve even the simplest issues.
All so completely co-dependent that they are an all or nothing proposition. Thus, one massive program.
CONFIG_FHANDLE is set. I am using Debian Jessie dist-upgraded yesterday.
Don't worry, there will be plenty of those. Here's one:
I am testing Jessie with systemd and find that systemd absolutely refuses to mount a btrfs filesystem in degraded mode even though I explicitly set the option in fstab.
Can anyone tell me how to either force it to at least attempt mounting or to have it leave fstab alone and call my script to do the mounting?
No, dropping to an emergency shell so I can mount it manually over IPMI is not an acceptable alternative.
Basically, systemd requires manual intervention to allow to boot btrfs arrays with both /a missing disk/ and in /degraded mode/
Not a bad default really.
But it's a terrible ONLY choice. I specified that degraded mode should be used if necessary, systemd ignored my setting.
Anyway, in order to allow btrfs to automatically boot in degraded mode with missing disks, and doing it /correctly/ you need some extra module/script/daemon to handle it, since neither the kernel nor systemd (udev) have any knowledge about the internal state of btrfs.
I WISH it had no knowledge. It apparently had enough to figure out that a disk was missing, but not enough to notice that I said mount anyway.
Nothing new in that, raid etc. have always been handled by such a daemon. I think that if you use mdadm with btrfs raid, you can automatically mount degraded mode arrays.
If I use mdadm with btrfs, I'm defeating much of the point of btrfs. Btrfs 'raid' is not literally a raid, it is similar but more flexible. But as for the actual md in Linux, the daemon is optional. mdadm is used to probe for and start the raid volumes, but from there it's up to the driver. You CAN run mdadm in monitor mode as a daemon if you like (and it is a good idea).
If you read the above discussions, you will find that there is no right solution for all; doing brute force attempts to mount missing drives or bring up raid arrays even though they may not be complete yet (a late drive will make the array degraded) have its own sets of problems, and differs whether it is a two drive or a 1024 drive array.
It has been working fine for over a decade now without systemd. In general for small volumes, if one drive hasn't managed to get ready by the time you're mounting filesystems, it is failing and needs to be kicked out of the array anyway. Mdadm can and WILL bring a raid up in degraded mode if at all possible. If you also run mdadm as a monitor, it will email you promptly about the degraded array.
Remember, RAID isn't just a way to make your data survive a drive failure, it is about high availability. A highly available system cannot panic at the slightest hint of trouble.
Also, it is not up to either systemd or udev to know about complicated raid states; that should be handled by the raid array software/daemon who can probe internal logic and then inform init what to do (or rely on crude timers).
Yes, yes, 1000 times YES! So why does it butt in and refuse to try mounting based on it's examination of what drives are part of the filesystem (internal state anyone)? Shouldn't it butt out and just issue the mount command and let the filesystem work it out? (or report failuer and so try again after the countdown)
Arrays come up R/W and degraded all the time. It's part of being highly available. If it's important enough, there's usually a hot spare and the array will begin rebuilding immediately. Btrfs may grow that feature one day, but until then, I might well have a cron job check on it and see if it needs a spare added (and run balance, of course)
As for all that about writing wrappers and daemons and such, isn't systemd supposed to be simple? That sounds like a lot of hoops to jump through just to get it to not do something obnoxious that it shouldn't be doing. I'm not wanting to do something odd here.
Hypothetically, my production box needs this fixed pronto. No time to wait for the committee to debate if this is WontFix or not. So, it sounds like my best bet is to tell systemd to ignore fstab entirely and run my scripot (borrowed from sysV) instead. What's the procedure for that?
That people use a rather cartoonish interpretation of what Unix Philosophy is to attack systemd, is another matter. That everything should be small single-function programs piped together with a text-only interface, simply isn't the case for the vast majority of Linux and Unix programs. It is a design ideal that no one really follows for anything remotely complicated. Even Vim isn't correctly designed by this cartoonish interpretation of Unix Philosophy.
It absolutely is true for system utilities (like init). Vim is a text editor. It edits text. It does not edit graphics, init the system, act as a login daemon or multiplex your shell. But then, it's not a system utility. Look at awk, sed, grep, less, etc etc. Look at getty and login. Look at screen.
Did you know that in Debian Wheezy there are TWO init systems that work at the same time? They weren't designed to do that but because they do things the Unix way, they don't 'mind' either.
But here's a "funny" where systemd is most definitely wrong (yes, I have actually been giving it a chance, I just don't like what I see). I have a VM where I have yanked a virtual disk out from under btrfs. My fstab states that I want it to mount in degraded state if necessary (such as if a disk is missing). systemd *REFUSES* even though I explicitly commanded the action. How is that the Unix way? How is that supposed to help uptime? Thank the gods it's not a production box! Then I google as to why that might be and first post I find is some someone claiming IT'S A FEATURE! So there we are, the admin and owner of the box says just do it and damn the consequences and it refuses like a Windows box.
Now, just to complete the picture, do you know what journalctl told me about what was failing and why? It said the mount timed out. THAT IS ALL. Is this the system I am supposed to trust in production? The one designed by people who KNOW what they're doing?
Digging in to it, I find the really sad part. It knows enough about btrfs to dig in to it and discover what physical drives go with the volume label. It wasn't even attempting the mount command fstab suggested (if it had, it would have succeeded). Surely after sitting in the penalty box for a minute and a half staring at the cylon, it could have given it a try?!? Or known a bit more about btrfs and seen that I intended a degraded mount? Or known less about btrfs and just done what fstab said to do?!?
It's a sick joke.
Perhaps. I suspect that the reason why such a feature never was developed was the usual catch 22: such a feature would change how init worked, making it incompatible with other init systems. Since no one could lead such a change, everything remained the same.
Actually, it would not. Why not a program that grabs the requested ports and other resources that require root, then drop privileges and pass them on to the daemon. It would drop right in to any sane init out there. It could even be used on a case by case basis. Launch apache with it but not postgres, etc.
Nothing prevents other Unix like systems in implementing similar features.
You seem pretty generous with OTHER PEOPLE's time. I'm fairly sure *BSD will never in a zillion years let systemd anywhere near their OS. They shouldn't! I'm also pretty sure a lot of daemon developers aren't going to sacrifice portability at the alter of systemd. If systemd wasn't such a tangle of dependencies, someone MIGHT implement limited bits of it in other OSes but if you hand them all or nothing, it's going to be nothing. Especially since systemd depends on a linux kernel only feature or 3.
Beauty is of course in the eye of the beholder, but perhaps your perception of systemd isn't without prejudice; many of the core systemd developers a really experienced Linux developers with deep expert knowledge about various aspects of low level system design.
Appeal to authority isn't a very good argument. Many really experienced developers with a deep expert knowledge about various aspects of low level system design think the design of systemd is crap. Many others consider it too immature for primetime.
Lennart Poettering has demonstrated through his designs that he does NOT understand the "Unix philosophy". If he did, the new init system would raise little controversy and would play much nicer with others.
No troll here. Just someone who apparently is a lot more likely to write that paper one day than you are. If you think I'm talking gibberish, it's because the argument is over your head. Had you been more polite about it, I might be more polite here.
Actually, systemd keeps all of that complexity and more, it just sweeps it under the rug and makes it into a single point of failure.
Also, unless the daemon decides it wants to give up all portability and lock itself into systemd, it has to implement all of that code anyway and ignore systemd. Or worse, it can add yet another compatibility shim and accommodate systemd as well.
Of course, a SIMPLE utility could do that job on a case by case basis and be usable by systemd or sysvinit or openrc, etc etc. It could also be portable to *BSD and OSX (unlike systemd). Systemd's 'design' reminds me of Robin Williams talking about God getting incredibly stoned and creating the platypus.
As a bonus, that approach wouldn't screw up a simple thing like fstab.
Meanwhile, where are these experts and those amazing code reviews?
More likely you can't answer the question.
And so I claimed that it actually is a good language to use, not just there by inertia.
In what way is Jit going to run faster than a binary pre-compiled after careful (and automated) profiling and tuning? JIT's advantage is in cases where the end user can't do a custom compile.
Trying to make a virtue out that of the fact that SysVinit is so crude and broken it exposes userland to potential data corruption is just plain denial.
No, it's just a healthy understanding of the KISS principle. There is a virtue to something too simple to screw up.
You seemed to feel that inertia was a big factor.
No JIT will be as fast as compiling once in advance for exactly the hardware it will run on. Especially given the chance to do time (and correctness) trials with various optimizations first. Interestingly, JIT and scripted languages make a lot more sense for small to medium clusters, particularly if they would see idle time anyway. In those, the pressure to get value from every cycle tends to be a bit lower such that saving development time and debugging effort may be worth it.
Pull your head out of the sand. The system did not come up far enough to do what you suggest even though it was clearly capable of it (since it did when sysvinit was in place).
What special treatment? Are you now claiming it is somehow going the extra mile for an ISP to actually do the bare minimum they already promised to do?
If you want to live like a nomad chasing ISPs, beat my guest, but there's probably an answer that will be much better for our society.
Since the report was that it was NOT possible to edit fstab with vim, however far it actually came up was not enough.
You don't get to just ignore the parts of the report you don't like and call the user an idiot.
No. It should at least come up far enough to diagnose and fix. Did you miss the part about not coming up far enough to edit fstab?
Easily done. Given the lack of dependencies on sysvinit, it just drops right in. Feel free!
FORTRAN is an excellent language for that sort of thing even though the standards people seem hell bent on screwing that up lately.
C is great for many things but it's too easy to have bugs that crash it in hard to diagnose ways. Interpreted languages have their place too, but not when absolutely maximum performance is a requirement.
It's probably more like 20 years, we've been pushing against a wall for a while now.
Given everything they have done, how can you even imagine they would hesitate to do that?
Bad people do bad things. Doubly so when the 'person' is of the legally incorporated multi-national variety.
The better argument against GP is the almost purely ad-hominem attack.
You're forgetting, the last time those very same telcos engaged in mass law-breaking on the behalf of the NSA, they got blanket immunity as a reward. Those who didn't cooperate got contracts terminated and a 'coincidental' string of denials on the regulatory front.
It may be dirty and crooked but not stupid to go ahead and do the MITM attack secure in the knowledge that at the end of the day their customers will be forced to eat the losses and have nowhere else to go for their telecommunications if anything goes bad.
You only get spanked if you don't cut the NSA in on the haul. That is NOT paranoia, it's a summary of recent history.
Moreover, the only way they could even do it would be to install trusted certificates on the phones that they sell. How long do you suppose that would fly under the radar before being discovered? Do you really think Google or Apple would go along with it? Use some common sense man....
The telcos have considerable latitude with the extra crap they bundle onto the phones. Do you really think Apple would rather not sell iFruits in the U.S. than agree to allow a few mandatory extras from the telcos?