Artix Linux Forum

Belligerence doesn't solve the problem. Stop being belligerent pricks. Artix was good up to this point. Then the pricks had to show their true colors...
Because there isn't any. No error message. Nothing. Nada. No diagnostic output of any kind, except for an obvious falsehood. Which I have posted multiple times. I'll post it again.

$ sudo sv start ssh-chat
timeout: down: ssh-chat: 1s, normally up, want up

That's it. That's all I got. If there's some secret hidey hole with more information, please tell. If it exists, it certainly hasn't been documented. A few passing, vague references have been made about redirecting something. No explanation of how I might do it, or even what it is. Since the writers of these statements didn't take it seriously enough to explain; in kind, I did not take it seriously. They did not think it important, so neither did I. My imagination waxes hopeful and sad at the same time... Is there, indeed, a secret hidey hole where nerds hide their mistakes? Is it possible that the human race is even worse than my cirrent understanding of it? Do I "redirect" it into the light, where I might see it? A part of me hopes it isn't true, because that would be really stupid. So incredibly stupid that I have a hard time believing it's real. Are you screwing with me? I'm certain it's a joke. That would be like putting the "check engine" light inside the oil pan. Nobody can see it there, so it does no good... Why even bother having it? That can't be true... But ... if it is, how do I do it...? I know I'm being trolled. There's no way something so ridiculous can be true. You're just screwing with me to see if I'll bite... That's so insane it can't be real. No serious person would hide diagnostic failure mode data where no one can find it. That would be the biggest dick move in the history of dick moves. I don't believe it.If runit is doing anything at all, there is no indication of it. I contend that, no, runit isn't doing anything at all. If it were, you'd show me how to unlock the puzzle box where it is hiding this information.
I'd love to learn. But, there are no teachers and no books, so learning isn't happening. I cannot absorb facts which are never presented or do not exist. Worse, I might "learn" many things which are untrue from fraudulent/incompetent documentation...

If I could avoid interactions with people of such low quality, it would be the greatest gain of my life. I would love nothing more. I don't want to be here. It's a last resort, because I know the sort of people I'll end up dealing with...

You notice every runit command starts with "exec," but in the entire volume of the runit documentation,"'exec" is not mentioned even once... Good job...

Just answer the question: Why doesn't runit function as documented?

If you truly believe runit is trying to do something and failing, why is it hiding the diagnostic information? That's silly. What kind of obnoxious brat would hide critical diagnostic information? Why would you keep errors secret? Why would you make it impossible to find out what's going wrong? Is it some weird, asian save-face thing? Never admit you're wrong. Newver admit msitakes. Help hide anyone else's mistakes by jettisoning all failure mode data into a black hole before the boss sees it! That's too absurd for me to accept. It can't be true. Even the most obnoxious person on Earth would not do such a thing.

Why does it work perfectly fine from CLI, but not in runit? A common mode of failure is that the execution environment is different from the user/CLI environment, so one must specify the full path absent a $PATH environment variable. I did that. It still doesn't work.

I'd love to learn. ...if there were something to learn. I keep asking, getting no answer, and then told that I don't want to learn... It seems my persistence in asking the question is making people mad, so they lash out with silliness...

I WANT TO KNOW! ANSWER THE QUESTION INSTEAD OF TROLLING ME! I NEED THE KNOWLEDGE! I CRAVE IT! I WANT IT! TELL ME WHY IT DOESN'T WORK AS THE DOCUMENTATION DESCRIBES! IF THERE IS SOME MAGIC SECRET ERROR HOLE WHERE DIAGNOSTIC INFORMATION IS HIDDEN AWAY TO PREVENT SOLVING PROBLEMS, PLEASE TELL ME! THAT SEEMS DUMB! WHY WOULD YOU BOTHER GENERATING ERROR INFORMATION ONLY TO HIDE IT? WHY PROVIDE A FAKE ERROR MESSAGE WHILE HIDING THE REAL ONE? WHY NOT JUST SHOW THE REAL ONE? WHAT KIND OF ELABORATE TROLL GAME IS THIS? WHO DOES SOMETHING LIKE THAT?

There is absolutely nothing wrong with asking for help for things you don't know, but when you barge in rudely, make ridiculous claims, and show just a complete lack of understanding or care for any of the things people have pointed out, we're all inclined to not bother. Anyway as per the output you posted, runit is clearly trying to start the service otherwise it wouldn't say "normally up, want up". Runit is just running the shell command you gave it. It's not "not working"; the command you gave is exiting with an error.

In a nutshell, learn what stdout and stderr is and how to redirect the output to a file so you can read it (as mentioned in a previous thread).

@camosoul Ignoring your inappropriate tone, we're just packaging runit and providing initscripts for it. We are not providing a script for ssh-chat. If you feel you can't tackle the problem yourself and we are not helping you, take the issue upstream to runit and/or ssh-chat.

Keep it polite, please.

Do unto others as you would have them do unto you.

My tone is only so due to the belligerence I've had to deal with thus far. I can ignore/endure a lack of breeding and manners for only so long before I give it back. When the rules of civil decorum are thrown out, I don't stand on delusion.

To put it in terms my present company might understand; If you don't want me to punch you in the mouth, don't be an asshole. If it has come to pass that I have already punched you in the mouth, it's because you're an asshole.

Moderately productive subject-related commentary: Lacking any other context, I'll interpret this literally.

$ sudo sv start ssh-chat 2>&1
timeout: down: ssh-chat: 0s, normally up, want up
$

OK, lets try this instead:

$ cat run 
#!/bin/sh
exec chpst -u ssh-chat /usr/bin/ssh-chat --bind=[ip]:[port] --identity=/path/to/chat/server/key/file --motd=/path/to/motd.txt --allowlist=/path/to/allowlist 2>&1
$ sudo sv start ssh-chat
timeout: down: ssh-chat: 1s, normally up, want up
$

Either there's nothing on stderr, or I am implementing the redirect improperly.

I comprehend the generic 0, 1,  and 2 file descriptors, I comprehend the > (and >>) redirector. I do not understand the &. To my knowledge, that has been used to throw a process into the background. It's not doing that here?

Footnote to self:
2: stderr
...it turns out that my previously noted "greatest dick move in the history of dick moves" is real... They really did install the "check engine" light in the oil pan. When you think clown world can't get any worse... You find out it's been that way longer than you've been alive... honk honk... My opinion of the human race has sunk lower, and I didn't think that was possible. There really is a secret nerd black hole into which nerds throw their mistakes so that they can never be found. They call it "2." And it is very much like asian save-face immaturity. They want to hide their mistakes so badly, they do it on your behalf, hiding error output so no one will see it, not even you...

I'd rather make my mistakes large and loud. Hard to miss. Easy to fix.

It's very hard to fix things when the errors are hidden. This is a sad day. But, hopefully, I can at least make runit work, even if I am lost in a black despair of limitless stupidity... My ears are still ringing. How can smart people be so stupid?

I'm not even sure I have the puzzle box unlock combination right... They really don't want anyone seeing error output... I hope cenobites aren't involved...

Runit scripts are written in sh not bash, there is plenty of documentation on sh (ie exec) to be found separately. If you need a more detailed understanding of what's happening, don't forget you can look at the Runit code which is the great benefit of open source. The actual implementation of Runit differs between distros (quite widely) and may not be exactly as laid out on the Runit website itself. There are some example scripts here:
http://smarden.org/runit/runscripts.html (http://smarden.org/runit/runscripts.html)
Many are much more complex than their short length implies, using all kind of tricks from both sh and runit to give the desired effect. It's also important to understand how the boot environment may differ from the regular one, not everything is available during boot  that you would find in the desktop, as it has not been started yet. Because the particular combination of enabled services differs between users it could even be something unique to your system, and in writing a custom non-functioning script you have created a problem which nobody else has, so you cannot expect any easy or instant answer when it does not yet exist.
Patience, you can spend days, weeks, months, researching a subject like this, Runit and the Runit doc's weren't written by Artix users either (well who can say who is using Artix) and if you find some things that you can explain better, then that is an opportunity for you to write a blog or make a video etc. to provide your contribution to make things clearer for future Runit users.
I am using OpenRC so cannot give any specific advice.   ;)
(But exec is also odd in that it replaces the script with the exec'd process so nothing after the exec happens, which might be your problem here.)

I started on OpenRC, waay back in my Gentoo days. That was roughly 2 decades ago. I tried OpenRC/Artix at first. I assumed it would be familiar. But, it had changed so much it was not familiar. Since I was essentially dealing with a blank slate no matter what, I figured I'd give runit a try, assuming simpler is better...

So you're saying ... get rid of the "exec" statement?

I learned the "execution environment might not be the CLI environment" lesson a while ago. Makes sense. In fact, it's dumb to expect it to be the same. Hence, full path statement, don't depend on $PATH environment variable existing, it probably doesn't.

$ cat run
#!/bin/sh
chpst -u ssh-chat /usr/bin/ssh-chat --bind=[ip]:[port] --identity=/path/to/chat/server/key/file --motd=/path/to/motd.txt --allowlist=/path/to/allowlist

$ sudo sv start ssh-chat
ok: run: ssh-chat: (pid 3017) 1s
$

However, attempting to connect renders connection refused... Dig moar, the service is not actually running, but sv/runit claims it is... Er, no?

$ sudo sv status ssh-chat
down: ssh-chat: 1s, normally up, want up

WUT?
So, it's running but it's not running? I don't understand... Is that "1s" a hint? Did it run for 1 second? And then die? What's going on... Just tell me the error you infernal contraption...

You need the exec but it has to be the last thing, anything else in the script needs to be done before then, you might use another helper service to run things afterwards, although quite probably there are other tricks to get that sort of effect. The script process becomes the daemon process that runit monitors and restarts if required. If you just want to run some commands in a "one shot" style you can do sleep 0 at the end instead of exec (runit monitors the sleep and thinks it's up) but it won't make a proper service so isn't reccomended.

I looked at a bunch of those example run scripts. I looked at the repo-provided ones, too. Not really helping. None of them skip "exec." It has to be the first thing on the line, according to all the examples.

$ cat run
#!/bin/sh
exec 2>&1
exec chpst -u ssh-chat /usr/bin/ssh-chat --bind=[ip]:[port] --identity=/path/to/chat/server/key/file --motd=/path/to/motd.txt --allowlist=/path/to/allowlist
$ sudo sv start ssh-chat
timeout: down: ssh-chat: 1s, normally up, want up
$ 

I'm still pulling teeth trying to get the damn thing to tell me the error message... It absolutely will not stop hiding it. Super, mega, top-secret error message! You're not allowed to know! If you knew, you might fix it! We can't have that! That would make too much sense! This is clown world! How dare you try to be rational and reasonable!

Redirect the ssh-cat output to a file.

daemon is the wrong word btw - runit needs processes to be in the foreground to monitor them, if they background themselves or run and complete without keeping running that requires some other approach. Not sure what your ssh-chat command does in that respect. If you run it on the command line and it just starts and doesn't give you the cursor back that's what runit likes, if you get the cursor afterwards it's not a foreground process.

It stays in the foreground. It's pretty simple.

I run it. I hit ctrl-c to make it stop. That's all there is.

Since I have no idea what the correct way to do that is, and no one on God's Green Earth can explain it, I'll try it the 3 ways I've seen so far.

$ cat run 
#!/bin/sh
exec 2 > poo.txt
exec chpst -u ssh-chat /usr/bin/ssh-chat --bind=[ip]:[port] --identity=/path/to/chat/server/key/file --motd=/path/to/motd.txt --allowlist=/path/to/allowlist
$ sudo sv start ssh-chat
timeout: down: ssh-chat: 1s, normally up, want up
$ cat poo.txt 
$ 

$ cat run 
#!/bin/sh
exec chpst -u ssh-chat /usr/bin/ssh-chat --bind=[ip]:[port] --identity=/path/to/chat/server/key/file --motd=/path/to/motd.txt --allowlist=/path/to/allowlist 2 > poo.txt
$ sudo sv start ssh-chat
timeout: down: ssh-chat: 1s, normally up, want up
$ cat poo.txt 
$ 

$ cat run 
#!/bin/sh
exec chpst -u ssh-chat /usr/bin/ssh-chat --bind=[ip]:[port] --identity=/path/to/chat/server/key/file --motd=/path/to/motd.txt --allowlist=/path/to/allowlist
$ sudo sv start ssh-chat 2 > poo.txt
$ cat poo.txt 
fail: 2: unable to change to service directory: file does not exist
timeout: down: ssh-chat: 1s, normally up, want up
$ 

This last one is the only one actually redirecting anything, but clearly not as intended. It seems to be redirecting stdout into the file. The top two result in an empty poo.txt, 0 bytes. It looks like sv is trying to start two services. One named ssh-chat and one named 2. Can't change to 2's service directory, because that's not a thing. The familiar useless, fake error then follows in the file instead of stdout. Nothing more has been discovered.


https://linuxize.com/post/bash-redirect-stderr-stdout/
This is what I'm working from. It assumes bash, this is sh I guess? I don't know if that matters. Probably. Who knows... I should have gone to bed 4 hours ago.

Why would such extreme efforts be made to block failure mode diagnostics? I can't take it seriously... This is ridiculous. If there's an error, print it on the damn screen. Adults have work to do.

Knock it all you want, at least Windows ME would make a loud noise and throw a pop-up on your screen telling you what the problem was, with a giant red x on it. No secret inspector gadget decoder ring needed to find that error message. A huge advantage over this disastertastrophe...

Out of frustration, boredom, and sleep deprivation. I just hit

up-arrow [enter]
up-arrow [enter]
up-arrow [enter]
up-arrow [enter]
up-arrow [enter]
up-arrow [enter]
up-arrow [enter]
up-arrow [enter]
up-arrow [enter]
up-arrow [enter]
up-arrow [enter]
up-arrow [enter]

about a million times, and, magically, it started working.

WUT?

I rebooted just to make sure, yep, it's working! Lolwut? What in the balls is going on?

I didn't change a damn thing from previous non-working... Oh whatever, this is so dumb... At this point I'll take the mulligan.

HONK!
HONK!

[img src=pepe_facepalm_meme.tga]

Now I need to figure out how to make it shut off gracefully. I guess I'll need to track the pid when it launches and do the [finish] executable script thing... It'll probably look something like

#!/bin/sh
kill [pid]

I don't want to deal with that now. I've had enough insane nonsense for one day.

...looks like PID is stored in supervise/pid, so that's convenient.

$ sudo cat /etc/runit/sv/ssh-chat/supervise/pid
798

Just read that file into a variable, kill $variable...

Holy crap it's working...

Anyone looking for a guide; DO NOT FOLLOW THIS. I have no idea why it's working now, but didn't work before. BEWARE. THIS IS STUPID. DON'T DO IT.

$ sudo sv stop ssh-chat
ok: down: ssh-chat: 1s, normally up
$ sudo sv start ssh-chat
ok: run: ssh-chat: (pid 1105) 0s
$ sudo sv stop ssh-chat
ok: down: ssh-chat: 0s, normally up
$ sudo sv start ssh-chat
ok: run: ssh-chat: (pid 1118) 1s
$

And it's not faking it like it did before. The service really is running. Clients can connect to it. Via tor and otherwise. It seems to be doing exactly what it should have been doing from the beginning.

$ cat run
#!/bin/sh
exec chpst -u ssh-chat /usr/bin/ssh-chat --bind=[ip]:[port] --identity=/path/to/chat/server/key/file --motd=/path/to/motd.txt --allowlist=/path/to/allowlist

$ cat finish
#!/bin/sh
pid=`cat /etc/runit/sv/ssh-chat/supervise/pid`
kill $pid

So simple.
This is what I tried the very first time and it wouldn't work.

I'm going to honk myself to sleep now.

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

Searching the web (or "googling") is one very popular, and mostly effective, way to get information. For example, it yields this answer (https://stackoverflow.com/a/13088401/184064).

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

man 1p exec

gives the manual page for exec(1p), a part of which is:


Redirections are explained in manual pages of most shells and in POSIX standard (https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap02.html#tag_23_02_07). For example, typing

man bash

followed by typing /^REDIRECTION and pressing Enter leads to the following section:
and so on. About the standard file descriptor numbers, they are explained in stdin(3p). See

man 3p stdin

for more information.

Now let's try an example:

$ 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:

$ 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 (https://github.com/shazow/ssh-chat/wiki/Deployment) 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 (http://smarden.org/runit/faq.html#userservices) 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.