23

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.

  • Well, Gilles was the first vote on that question, so maybe we should ask him. – Braiam Apr 22 '14 at 6:53
  • 1
    @Braiam Yeah, that's part of my confusion. But I don't want to call him out, I want to be clear this isn't "@Gilles, WTF are you doing?!": it was after all an answer he left in 2010. There's nothing wrong with him changing his opinion since then. And it's not just his vote to close; 4 other people agreed with him. – derobert Apr 22 '14 at 6:55
  • 4
    What's wrong w/ "@Gilles, WTF are you doing?" WRT "4 other people agreed w/ him", I'd bet 98%+ of things that enter the close queue get closed, so in that sense, either the people who cast the initial votes are 98%+ accurate in their judgement or in reality it only takes 1 vote + 4 rubber stamps to close a question. – goldilocks Apr 22 '14 at 11:59
  • I gotta agree with Gilles on this as well. – slm Jun 8 '14 at 2:00
  • Come back, @goldilocks... – mikeserv Jun 8 '14 at 3:22
8

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.

  • 3
    I disagree with making Unix system programming on-topic, not only because it would be a major change to the site's scope for no good reason, but also because the resulting scope would be brittle. See my answer for a more detailed explanation. Unix kernel programming is even worse: that is very far removed from user and administrator experience — apart from RTFS, users and administrators never see the insides of the kernel. – Gilles Jun 8 '14 at 1:24
  • 1
    Unix programming can be done in lots of languages, i.e. in Perl or Python, or a slew of others. All on-topic?! – vonbrand Jun 12 '14 at 1:18
  • @vonbrand Do people do Unix system programming or kernel programming in Perl or Python? – Faheem Mitha Jun 12 '14 at 8:02
8

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.

  • Occasionally C code will appear in answers, generally when the answer starts with “there is no standard shell command to do what you want”. But if C code appears in a question, it's almost always on-topic. The difference between administrator scripting and programs that programmers write isn't only or even primarily the language, but also the complexity. A Perl one-liner would be ok here, but not a 5kLoC Perl application. – Gilles Jun 13 '14 at 1:37
  • 1
    @Gilles I agree with you that complexity is important, and my suggesting is that the complexity be limited to essentially no more than just calling the API function. Which does cover the mount question. – derobert Jun 13 '14 at 1:39
7

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.

  • unlink and remove man pages for the curious. – Cristian Ciupitu Jun 21 '14 at 22:39
  • 2
    I agree with everything you wrote in the general, but you seem to have misapplied your thinking to that particular user's question. He didn't ask How do I write a C program but How do I write a C program to implement a very specific system administration task. The same reasoning you use to justify shell programming (as an edge case) seems to me to apply here. StackOverflow is also used to apply to narrowly-applied programming questions; I use it all the time for that. But his question is much more specific to Unix&Linux than it is to coding. Further, there's no requirement an answer... – Otheus Nov 27 '15 at 0:38
  • 1
    ... must be specific in terms of code. Generic answers such as "look at the man page, section 2 of mount" and "look at the source code for the mount program implemented on busybox" and "ask at stackoverflow for more detailed questions" would suffice, be more useful to the user and others that follow, while still retaining the spirit of what you wrote above and the guidelines (as I understand them from the OP). – Otheus Nov 27 '15 at 0:41
0

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.

  • 1
    The "How do I write a C program that will implement the above line." may weighed in the decision. – Braiam Apr 22 '14 at 6:58
  • 2
    Then "What do I pass to mount(2) to mount /sys?" would be on-topic? That seems like language-lawyering, not a sane way to define the scope of our site. Would "What's the Linux system interface to mount a file system?" be on topic? – derobert Apr 22 '14 at 6:59
  • 2
    @Braiam exactly. the question was fundamentally about writing C code. – strugee Apr 22 '14 at 6:59
  • @derobert no, your first example would be off topic because its a programming question in a mask. your second example would be borderline. an example of a question that would definitely be on topic is "why does glibc wrap mount()?" – strugee Apr 22 '14 at 7:03
  • 3
    I think you'll want to propose new wording for the help center, as currently it says the "UNIX C API and System Interfaces" is on-topic. As it seems really hard to say that its not OK to ask about how to call it in C, when you're calling it the C API. – derobert Apr 22 '14 at 7:06
  • 1
    ... especially since you can't actually use (directly) the C API from bash or other scripting languages. – derobert Apr 22 '14 at 7:08
  • true... hmmm... – strugee Apr 22 '14 at 7:19
  • 1
    @derobert The audience of this site is users and aministrators of Unix-like systems, not programmers. If you're seeing the system interfaces from a user's or administrator's perspective, it's on-topic. If you're seeing it from a programmer's perspective, as in the question that prompted your meta question, it's off-topic. – Gilles Jun 8 '14 at 1:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .