Forgot your password?
typodupeerror

Comment: Re: Administrators dislike constraint based system (Score 1) 851

I don't like the part that overwrites resolv.conf to use 127.0.0.1 as the nameserver if it thinks the network is down, but I'm not going to play shell script bug hunt with you. SystemD also has bugs. Almost all software has bugs. The software on Apollo 11 had bugs. And Debian's init scripts are, indeed, messy and imo overkill and inferior to the rc.d method used by Slackware and the BSDs.

I'll just leave you with this: https://plus.google.com/112984...

Yes, yes, "it's just an interface to journald!" So it's more like syslogd embedding a web server and QR encoder than init itself. Much better.

Comment: Re: Administrators dislike constraint based system (Score 1) 851

Well, the problem in your example wasn't a race condition. It's that they never did kill -9.

The comparison with the SystemD version of the file is invalid because the complexity has just been shifted elsewhere. In the init version, the complexity is in the script. In the SystemD version, it's in a monolithic binary running as PID 1. Which is better is not clear just from looking at the files.

However, and I've said this before -- even if Debian's init scripts suck, that just proves /Debian's/ init scripts suck. Slackware's init scripts are much, much cleaner than Debian's or Red Hat's.

You might want to look into some sort of "(sleep 600; reboot -f ) &" inside of your shutdown script if you're going to be working with machines you can't easily get to to power cycle. That would potentially solve all sorts of obscure corner cases in shutdown. You'd have to put that in after it did its final "I KILL YOU ALL MWA HA HA" signaling to shut down the user processes so the sleeping shell doesn't just die with the rest of userspace. Still, might want to look into it.

Comment: Re: Administrators dislike constraint based system (Score 1) 851

The one I see is if you try to stop and start it simultaneously (or, "within a racy amount of time"), there could be a race with the PID file. Theoretically I guess you should have a consistent state if you start and stop the daemon simultaneously (either it should end up stopped or started), but it seems like it would be bad practice to attempt to do something like that. Slackware's rc.bind script has this comment, which is hilarious:

# Start BIND. As many times as you like. ;-)
# Seriously, don't run "rc.bind start" if BIND is already
# running or you'll get more than one copy running.

Sound logic. I learned not to blindly run "rc.whatever start" long ago.

You want people to test code on weird clusters that apparently are tightly integrated somehow and not using a standard batch submission mechanism. I used to want people to test code on Linux/SPARC. Neither of us is going to get what we want, because expecting other people to test such marginal use cases is expecting other people to do our work for us.

And why would you have to manually power cycle a machine because named didn't start? And why would you have to fix a failure on a single node of a huge cluster overnight? If that was the nameserver for all the machines, well, you should have had at least two nameservers. It's not like they take much CPU. Single points of failure are bad.

Comment: Re: Administrators dislike constraint based system (Score 1) 851

Dude I call bullshit on you. You're talking about theoretical problems that no one ever really runs into ever. There are 2^15 PIDs available. You're not going to iterate over all of them and actually run into a PID race in an init script. That is not a thing. It's just something you might learn in an OS class or something because, well, it /COULD/ be a thing in that theoretically there is a race there, so it's good for learning about races (I guess...). But it's not a race you're ever going to run into in a million years unless you have a fork bomb in your startup scripts. And if you have a fork bomb in your startup scripts, you have bigger problems. And if your entire cluster is freezing because of that one node, maybe you should work on that single point of failure since computers _DO_ have hardware failures occasionally and you _ARE_ likely to get bitten by having a single point of failure like that.

But not because of sysvinit. Stop making shit up.

And you have a slightly lower UID than I do. Which means you should have grown out of your "disparage people who have more experience than I do because I'm so cool" adolescent phase by now. Stop talking about people who "can't see past their bash manual". That's not a thing, either. Having experience is a good thing. Unless you changed careers, you should have enough of it by now to see that. Look in the mirror and think about why your personal growth might maybe be going a little slower than it should.

Oh, SystemD? Well, I think those programmers should probably have spent their time solving real problems, and I'm suspicious of it, because it seems like it's reinventing the wheel, because of its questionable design decisions thus far (such as binary log files), and because Poettering's other brainchildren like PulseAudio are best avoided. But, given that there seem to be enough people who dislike it to support at least one mainstream distribution, I'm pretty sure I won't be stuck with it, so, if someone else likes it, good for them.

Comment: Re:Fedora fork too (Score 1) 555

by linuxrocks123 (#48199139) Attached to: Debian's Systemd Adoption Inspires Threat of Fork

If you want to query the service status, use ps aux | grep sendmail

And if sendmail dies, well, I would want it to stay dead so I would notice and look into why it died, but if you really wanted auto-restart, you have a number of options:

- Put "while true; do if ps aux | grep -v grep | grep -q sendmail; then /etc/rc.d/rc.sendmail start; done" somewhere.
- (The right way): put the command to start sendmail (not the startup script, sendmail itself) in inittab with the :respawn: option. You'll have to make sure to use the "foreground" option if you choose this route.

Comment: Re:Fedora fork too (Score 1) 555

by linuxrocks123 (#48199017) Attached to: Debian's Systemd Adoption Inspires Threat of Fork

As sibling said, this was Slackware's script, so you're actually criticizing its implementation of the BSD rc.d system.

And they are valid criticisms -- unrelated processes called sendmail would also get killed -- but my response would be, "yes, but, well, I've never run into that." If you stop sendmail, I think you should expect that some email might be dropped. You could easily create a sendmail.pid file in the script if you wanted, but I think keeping the script simple has greater value than catching those corner cases.

Comment: Re:Fedora fork too (Score 4, Informative) 555

by linuxrocks123 (#48192835) Attached to: Debian's Systemd Adoption Inspires Threat of Fork

All that proves is that Fedora's init scripts suck. I'll believe that.

Here's Slackware's rc.sendmail script:

#!/bin/sh
# Start/stop/restart sendmail.

# Start sendmail:
sendmail_start() {
    if [ -x /usr/sbin/sendmail ]; then
        echo "Starting sendmail MTA daemon: /usr/sbin/sendmail -L sm-mta -bd -q25m" /usr/sbin/sendmail -L sm-mta -bd -q25m
        echo "Starting sendmail MSP queue runner: /usr/sbin/sendmail -L sm-msp-queue -Ac -q25m" /usr/sbin/sendmail -L sm-msp-queue -Ac -q25m
    fi
}

# Stop sendmail:
sendmail_stop() {
    killall sendmail
}

# Restart sendmail:
sendmail_restart() {
    sendmail_stop
    sleep 1
    sendmail_start
}

case "$1" in
'start')
    sendmail_start ;;
'stop')
    sendmail_stop ;;
'restart')
    sendmail_restart ;;
*)
    echo "usage $0 start|stop|restart"
esac

Comment: Re:That's all we need ... (Score 1) 555

by linuxrocks123 (#48192821) Attached to: Debian's Systemd Adoption Inspires Threat of Fork

it's the future whether I like it or not. And I don't

SystemD clearly has enough adoption that it won't be going away any time soon. Some people, for whatever reason, want an init system that works like that. But other people clearly don't like it. Many of those people are programmers and now want to fork Debian. Even if that fizzles, there's still Slackware and at least Funtoo which are not using SystemD. Funtoo in its FAQ is committed not to using SystemD. Slackware isn't committed, but I think mainly because Volkerding knows to "never say never". But Slackware got rid of GNOME with its annoying PAM dependency long, long ago, so GNOME won't be forcing anything on Slackware, and Slackware uses BSD-style init rather than SystemV, so it was already an init outlier before all of this started. The point is, people who don't like SystemD will coalesce around the distributions not using it, or set up their own, and do the work necessary to keep them not using it.

Just like with the shutdown of FreeCrypt, there are enough people around who think this is important that they will be able to coalesce and do something about it.

Comment: Re:Why is the school involved? (Score 1) 323

Damnit Slashdot!

Corrected post is here.

The US does libel and slander pretty well. For instance, if you're slandering/libeling a public figure, the burden of proof the public figure bears is higher than if you're talking about some random dude. The libeled individual has to prove the statement is false. There are cases of abuse, such as where someone gets sued by a rich person just to harass. It's not perfect. But I think anti-SLAPP laws are a better fix for that than saying, "it's perfectly okay to spread vicious lies about anyone you want."

It's true that popular speech doesn't need protection. But it's one thing to say, "I think <insert race or gender or hair color here> people are a bunch of savages, and they should all be locked up!" It's another thing to say, "This particular <insert race or gender or hair color here> person is a pedophile, raped my wife, and tortures animals for fun!" One of these things is stupid, but rightly protected speech. The other is harassment of a particular individual. There's a difference.

Comment: Re:Why is the school involved? (Score 1) 323

The US does libel and slander pretty well. For instance, if you're slandering/libeling a public figure, the burden of proof the public figure bears is higher than if you're talking about some random dude. The libeled individual has to prove the statement is false. There are cases of abuse, such as where someone gets sued by a rich person just to harass. It's not perfect. But I think anti-SLAPP laws are a better fix for that than saying, "it's perfectly okay to spread vicious lies about anyone you want."

It's true that popular speech doesn't need protection. But it's one thing to say, "I think people are a bunch of savages, and they should all be locked up!" It's another thing to say, "This particular person is a pedophile, raped my wife, and tortures animals for fun!" One of these things is stupid, but rightly protected speech. The other is harassment of a particular individual. There's a difference.

Comment: Re:Why not? When you have kids.. (Score 1) 323

So, your system would have people able to say anything, and then you read someone's mind to figure out he didn't hire you, or didn't invite you to his party, or stopped being your friend because he thought you're a pedo, and then you sue all those people. Meaning you're making EVERYTHING a protected class for the purposes of hiring and killing freedom of association while you're at it. That sounds like a much more restrictive world to me than the current one, which just has, "don't spread nasty lies about people" as the prohibition.

Comment: Re:Parallels exist in animals (Score 1) 87

Human nature is the same as all other nature.

I'll be more serious now: no, it's not. We fit the definition of animals, yes, but we're freaks of nature. We're smarter than all other animals we know of; our brains have more synapses than any other animal we know of; we have more complex societies than any other animal we know of; and, we've been able to harness more energy in directed ways than any other animals we know of (exhibited by electrical grids, cars, planes, and rockets that leave the fucking atmosphere and send objects into space). You wouldn't necessarily expect, say, a mouse or fish to have the same problems with emotional neglect that human children have if they aren't "shown love" but still have all their basic nutritional needs met. That's something that's going to fuck up humans much, much more than most other animals. It'll fuck up monkeys (someone did a morally reprehensible experiment, referred to elsewhere in this thread, that proved that). According to the GP, it'll fuck up dogs, too, which you might expect since they're relatively smart. But you can't go the other way. You can't say, "this level of social interaction is fine for my dog, so my kid'll be fine if I treat him like that, too". Because we're not like dogs. We're an extreme of nature. We're freaks.

Never make anything simple and efficient when a way can be found to make it complex and wonderful.

Working...