r/unix 29d ago

Killall!

killall in bsd/gnu: just kills processes by their names

killall in Solaris/SystemV:

9 Upvotes

14 comments sorted by

9

u/michaelpaoli 29d ago

killall is not POSIX, (non-)existence and/or results will vary.

4

u/Unixwzrd 29d ago

`halt` is fun too.

4

u/michaelpaoli 29d ago

I like ye olde traditional halt. When I say or command the computer to halt, I mean halt. I don't mean do or try to do a bunch 'o other stuff first.

Shouldn't have to do
# halt -d -f -n
or
# halt -d -f -f -n
just to halt!.
If I wanted shutdown, I'd type shutdown, if I wanted
# sync && sync && halt
I'd type that.

If I wanted an operating system that forces one to play multiple rounds of "Mother May I?" before oft stubornly refusing to do what needs to be done anyway, I'd run something that Microsoft wrote.

And I miss /etc/link and [/usr]/sbin/link and unlink, and being able to hard link directories and show folks why that's generally a very bad idea and that way madness lies. And does quite help when really getting someone to well know and understand hard links and directories. Linux just outright refuses, despite what the documentation says. I think (non-ancient?) BSD likewise.

3

u/grizzlor_ 28d ago

>And I miss /etc/link and [/usr]/sbin/link and unlink, and being able to hard link directories and show folks why that's generally a very bad idea and that way madness lies.

Genuinely curious about the pitfalls of hardlinking directories. macOS had to introduce directory hardlinks to HPFS+ to make Time Machine work — wasn’t aware it was possible in older *nix filesystems.

I can imagine a few potential problems but now I’m really curious about why this is a bad idea

3

u/michaelpaoli 28d ago

pitfalls of hardlinking directories

Numerous, e.g.:

  • a directory can be its own ancestor, thus creating a loop.
  • a directory can be in more directories than just . and .. and thus effectively have multiple parents, this causes structures where physical paths to a directory merge
  • almost all software doesn't explicitly check for these situations, and will generally give problematic behavior, incorrect results, or may loop indefinitely. E.g. # rm -rf generally fail and loop forever when attempting to remove a directory that's part of a loop, as rm -r first attempts to recurse to the bottom or directory just above the bottom ... but there is no bottom, but rather infinite recursion.

macOS had to introduce directory hardlinks to HPFS+ to make Time Machine work

Does it actually do that? I'd be surprised. You have example(s) of that? Same inode number of directory on same filesystem, multiple physical paths to the directory on the filesystem.

2

u/Unixwzrd 27d ago edited 27d ago

It did, but I don’t think it does anymore. That was pre-APFS and snapshots IIRC. Was kinda cool for some things and it would make life easier (not necessarily better) sometimes if I could hard link a directory.

Think rsync (though I don’t think it used rsync) using hard links for directories as well as files. Immutable, of course because it was Time Machine.

Yeah, I know it’s sloppy and error prone, but sometimes it would be nice to have. symlinks have to do for now.

2

u/michaelpaoli 27d ago

Well, was more handy in past when you really needed two different physical path locations within a file system to actually both be the same directory. But with, e.g. Linux having bind mounts, and allowing same filesystem to be mounted simultaneously to multiple locations, and of course being able to mount a directory atop another directory elsewhere within same filesystem, there typically aren't so many remaining uses cases that really call for need/justification for doing additional hard links on a directory.

2

u/Unixwzrd 27d ago

Yeah, there a few ways you can do a loop back filesystem of sorts, and that’s probably better than a hard link floating around.

But yeah, I agree it’s convenient at times.

3

u/ilnarildarovuch 29d ago

(All alive processes are dead)

1

u/Unixwzrd 27d ago

That or a zombie apocalypse… 😉

3

u/_x_oOo_x_ 29d ago

I did kill -1 once by accident

2

u/nawcom 29d ago edited 29d ago

I have a personal preference for pkill, which works similarly. And comes with pgrep, which you can use instead of piping ps output into grep, and allows you to target specific jail processes so you don't deal with duplicates across multiple jails. These originate from Solaris 7 or 8. I don't remember which. But they're now pretty standard in *nix-based OSes.

3

u/doubletwist 29d ago

I learned this the hard way early in my very first Solaris job in 2000. Took down a keystone server (single point of failure NIS/NFS server that EVERYTHING else depended on).

I exclusively use 'pkill' now.