Is the Unix C API still on-topic?

Question

According to Unix C API calls ontopic? and the help center, "UNIX C API and System Interfaces ( within reason )" is explicitly on topic. That within reason links to the meta question.

https://unix.stackexchange.com/questions/125744/mounting-a-file-system-using-a-c-program seems to be within that. Note that:

1. mount(2) seems like a common UNIX interface. Well, it's a Linux-ism, though the API is at least similar on e.g., FreeBSD. I don't think it falls under "very different systems like Cocoa."
2. "shell interfaces tend to be pretty close to the syscall interfaces" definitely applies here; more or less the mount(8) utility takes the exact same parameters.
3. It doesn't require any real knowledge of C, or of programming. It's the same knowledge you'd need to, for example, understand the output of strace /sbin/mount …. So, it seems to follow the guideline given:

   The guideline is: will the question interest only programmers, or also users and administrators? A sysadmin debugging why a server won't start with truss/strace output is on-topic here. A programmer debugging why his kernel module is causing an OOPS is off-topic. (From Gilles' answer to the meta question).

But as I was writing this, it was closed & migrated to Stack Overflow.

I don't understand—it seems to clearly follow the rule spelled out in the Help Center, seems to follow the +13/-0 consensus written by Gilles and linked into the rule.

Yet it was closed. With a vote from Gilles and several other regulars no less. So either I don't understand Gilles' consensus post, or his opinion has changed—and many others' in the community, too.

Either way, we need to fix something: clarify the consensus & the rules, change the rules to give the new consensus, or stop closing questions like that.

Answer 1

Small amounts of certain types of programming are reasonably within the scope of what a system administrator does.

Uncontroversially, writing a shell script to start a daemon, check if its running, and stop it is within scope (i.e., an init script). So is a shell scripting to automate system administration tasks, configure the environment for users (e.g., login and X11 startup scripts).

Fairly uncontroversially, we extend that to other scripting languages: Perl has been used for a long time by systems administrators, as has awk. More recently, Python and Ruby have joined that club as well.

But there has actually been another language in the sysadmin's toolbox, before even awk and Perl, before even shell. Sure, we avoid using it when we don't have to (it a much harder to use, more dangerous tool)—and even when we do use it, we read it far more than we write it. We see it all the time in our man pages; we read it when even searching the fine web fails; we write it when we have no choice. That language is, of course, C.

It's true that not all sysadmins know C—even enough to read it. But the same can be said of Perl, LDAP, or Linux. That's not a reason for it to be off-topic.

Let me give one example of a sysadmin task that I solved with C—and I think it is pretty unambiguously a sysadmin task:

I had a NFS server go down. The mount was set up such that umount -f would kill all the programs accessing it, but allow the un-mount to succeed. Except when I tried to do the umount -f, it hung. strace revealed it was trying to stat the mount first—which if course hung, as the server was down. Even --no-canonicalize did not help; turns out I'd hit a bug in umount(8). I reported Debian bug #642331 about it, but of course, I still had a machine to fix.

I know that umount(8) is a wrapper around the umount/umount2 system call. So just call it from Perl, right?

$ perl -MPOSIX=umount2
"umount2" is not exported by the POSIX module
Can't continue after import errors at /usr/lib/perl/5.18/POSIX.pm line 30.
BEGIN failed--compilation aborted.

(That's a different version of Perl than I had at the time, but same problem. And no, umount doesn't work either. Not surprising; the calls are not in POSIX.) A quick search of other Perl modules installed on the system didn't find one to call umount2. You can see in the bug report the actual solution I used:

#include <sys/mount.h>
int main() {
    const char p[] = "/mnt/portal-dev/customer-portal";
    umount2(p, MNT_FORCE);
    umount2(p, MNT_FORCE);
    return 0;
}

And that worked, avoiding me having to perform an unscheduled (and disruptive) reboot.

That's a simple C program to solve a systems administration problem. I believe other sysadmins (for example, those not familiar with C) ought to be able to come here for help avoiding their unplanned reboots. That's why I think simple C which is essentially no more than making a call to the UNIX C API ought to be on topic.

Answer 2

Having looked at this question, it is pretty clearly about Unix system programming, which is in C by definition, but which comprises a small subset of C programming. This belongs on a Unix site if anything does, in my opinion. I'd suggest adding a clarification/exception to the no programming rule, that Unix system programming is in scope. I agree with @derobert's implied stance that something so Unixy does belong here.

The Help Center has the following language:

If your question is a programming question, requiring knowledge of programming languages other than unix shell scripting languages, ask on Stack Overflow.

I suggest adding Unix system programming as an explicit second exception.

Additionally, one could change (in the Help center)

UNIX C API and System Interfaces

to

UNIX C API and System Interfaces, including Unix system programming

Edit: I'd also add an exception for Unix kernel programming.

Answer 3

In https://unix.stackexchange.com/questions/125744/mounting-a-file-system-using-a-c-program, what makes the question off-topic is “How do I write a C program”. In the previous discussion, I wrote (in an answer that seems consensual: no downvotes, no opposing views in comments or other answers) that the system interfaces (system calls and certain C library functions) are on-topic. But that doesn't make using the system interfaces in a programming language on-topic!

Typical ways in which system interfaces arise on this site are:

• in the output of truss/strace/…, in auditd logs and configuration, …;
• when reading the source of a program (RTFS) to understand what's going on;
• to explain the architecture of a unix system, e.g. showing that some programs behave in a similar way because they're using the same system interface underneath.

In a nutshell, this is a site for users and system administrators. We redirect all programming questions to Stack Overflow¹. If the answer calls for code in a particular programming language, that's a programming question.

---

I disagree with making “Unix system programming” an exception. When it comes to user and administration questions, we're inclusive: questions don't have to be about applications that are specific to unix; you can ask a question about a cross-platform application, as long as you're using it on some unix variant. This is eminently sensible as users don't have to be aware that an application also works on some other platforms. Vim and KDE have been ported to Windows, but we wouldn't want them to be off-topic here. So why would we react differently to programming questions? It would presumably mean that a question about using unlink in C would be on-topic (it's a POSIX API), but a question about remove would be off-topic — yet remove on unix is a thin wrapper around unlink!

It would make sense to have a site that caters to users, administrators and programmers on all Unix-like systems. On such a site, programming questions in any language would be on-topic as long as the program is meant to run on a unix system. However, this is not the site we built. We didn't build such a site because Stack Overflow already existed and catered reasonably satisfactorily to all programming questions.

¹ _{Shell programming straddles the border as it is the primary way for users and administrators to automate many tasks, rather than a tool to make applications.}

Answer 4

I think I can tell you the problem with that question.

The problem was that a UNIX C interface was the solution to the question. The question was not about UNIX C APIs - not really. It was about programming in the UNIX environment. And as the help center states, any programming question is off topic unless it contains the use of a shell script.

Hence, the migration to Stack Overflow.