Skip to main content
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: runit still doesn't work (Read 1603 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Re: runit still doesn't work

Reply #15
Since my previous brief posts were ignored or dismissed as "arrogance", let's try with the more verbose approach.

Since I have no idea what the correct way to do that is, and no one on God's Green Earth can explain it,
Searching the web (or "googling") is one very popular, and mostly effective, way to get information. For example, it yields this answer.

But even without that, in Unix-like systems, manual pages explain most of the details such as this one. However, to use manual pages one needs to have patience and a stable attention span, something that most people seem to lack these days. Knowing key bindings for less(1), pager program used by man(1), also helps. (For example, pressing / and typing a regular expression, followed by Enter, allows one to forward-search for text satisfying that regular expression inside the manpage. Pressing n finds the next occurence, N goes back.) But I digress.

Typing
Code: [Select]
man 1p exec
gives the manual page for exec(1p), a part of which is:

Quote
NAME
       exec — execute commands and open, close, or copy file descriptors

SYNOPSIS
       exec [command [argument...]]

DESCRIPTION
       The exec utility shall open, close, and/or  copy  file  descriptors  as
       specified by any redirections as part of the command.

       If  exec  is  specified  without command or arguments, and any file de‐
       scriptors with numbers greater than 2 are opened with associated  redi‐
       rection  statements,  it  is unspecified whether those file descriptors
       remain open when the shell invokes another utility.  Scripts  concerned
       that  child  shells could misuse open file descriptors can always close
       them explicitly, as shown in one of the following examples.

       If exec is specified with command, it shall replace the shell with com‐
       mand  without  creating a new process. If arguments are specified, they
       shall be arguments to command.  Redirection affects the  current  shell
       execution environment.

Redirections are explained in manual pages of most shells and in POSIX standard. For example, typing
Code: [Select]
man bash
followed by typing /^REDIRECTION and pressing Enter leads to the following section:
Quote
REDIRECTION
       Before a command is executed, its input and output  may  be  redirected
       using  a special notation interpreted by the shell.  Redirection allows
       commands' file handles to be duplicated, opened, closed, made to  refer
       to different files, and can change the files the command reads from and
       writes to.  Redirection may also be used to modify file handles in  the
       current  shell execution environment.  The following redirection opera‐
       tors may precede or appear anywhere within a simple command or may fol‐
       low  a  command.   Redirections are processed in the order they appear,
       from left to right.

       Each redirection that may be preceded by a file descriptor  number  may
       instead be preceded by a word of the form {varname}.  In this case, for
       each redirection operator except >&- and <&-, the shell will allocate a
       file  descriptor  greater than or equal to 10 and assign it to varname.
       If >&- or <&- is preceded by {varname}, the value  of  varname  defines
       the  file descriptor to close.  If {varname} is supplied, the redirect‐
       ion persists beyond the scope of the command, allowing the  shell  pro‐
       grammer to manage the file descriptor himself.

       In  the  following descriptions, if the file descriptor number is omit‐
       ted, and the first character of the redirection operator is <, the  re‐
       direction  refers  to  the  standard input (file descriptor 0).  If the
       first character of the  redirection  operator  is  >,  the  redirection
       refers to the standard output (file descriptor 1).

       The  word  following the redirection operator in the following descrip‐
       tions, unless otherwise noted, is subjected to brace  expansion,  tilde
       expansion,  parameter  and  variable  expansion,  command substitution,
       arithmetic expansion,  quote  removal,  pathname  expansion,  and  word
       splitting.  If it expands to more than one word, bash reports an error.

       Note  that  the order of redirections is significant.  For example, the
       command

              ls > dirlist 2>&1

       directs both standard output and standard error to  the  file  dirlist,
       while the command

              ls 2>&1 > dirlist
and so on. About the standard file descriptor numbers, they are explained in stdin(3p). See
Code: [Select]
man 3p stdin
for more information.

Now let's try an example:
Code: [Select]
$ cat redir
#!/bin/sh
exec 2>cat.err
exec 1>cat.out
exec cat foo
$ ls -l redir
-rwxr-xr-x 1 strajder strajder 53 Mar 20 13:58 redir
$ ./redir
$ cat cat.out
$ cat cat.err
cat: foo: No such file or directory
if we change the file to:
Code: [Select]
$ cat redir
#!/bin/sh
exec 2 >cat.err
#     ^--- note the space between file descriptor number and redirection operator
exec 1>cat.out
exec cat foo
$ >cat.out; >cat.err
$ ./redir
./redir: 2: exec: 2: not found
$ cat cat.out
$ cat cat.err
$
When the shell parses a command, it cannot know if you meant to run the command "2" or redirect the file descriptor with that number. It sees a space and parses the parameters to exec as:
  • program called "2",
  • redirection: ">cat.err" (stdout to cat.err).
Since there is no program called "2", first exec gives an error and further script execution is terminated.

Similar thing happens in your other examples, "2" gets passed as an argument to different commands, instead of redirecting output to a file.

Now you see why there is nothing "elitist" nor arrogant in telling those who want to write services for various init systems that they first need to know the internals of GNU/Linux, shell command language and the specifics of init they are writing the service for, before engaging in such an activity. It is comparable to someone wanting to create a space shuttle without knowing elementary school physics. Writing services is not something an average user should need to do or should know to do. If you still want to do that, that is commendable, but you first need to learn to walk before you can run. Changing the immature attitude displayed in your other posts so far would also help immensely.

As far as ssh-chat goes, its wiki seems to indicate that a user service is desirable if one wants to run it as a service. That's why I linked the page describing how to create user services in runit in the other thread, but you seem to have simply ignored that post, instead concluding that "runit doesn't work".

runit works perfectly if you know how to use it.