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 1604 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

runit still doesn't work

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...
Quote from: a typical linux prick
why don't you simply look at the debug output
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.
Code: [Select]
$ 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.
Quote from: a typical linux prick
Runit is trying to start the command as indicated, but it is failing for some reason.
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.
Quote from: a typical linux prick
OP obviously has no intention of learning anything.
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?

Re: runit still doesn't work

Reply #1 –
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).

Re: runit still doesn't work

Reply #2 –
@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.

Re: runit still doesn't work

Reply #3 –
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:
Quote
something something 2>&1 something something
Lacking any other context, I'll interpret this literally.
Code: [Select]
$ sudo sv start ssh-chat 2>&1
timeout: down: ssh-chat: 0s, normally up, want up
$
OK, lets try this instead:
Code: [Select]
$ 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...

Re: runit still doesn't work

Reply #4 –
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
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.)

Re: runit still doesn't work

Reply #5 –
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?

Re: runit still doesn't work

Reply #6 –
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.
Code: [Select]
$ 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
Code: [Select]
$ 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?
Code: [Select]
$ 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...

Re: runit still doesn't work

Reply #7 –
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.

Re: runit still doesn't work

Reply #8 –
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.
Code: [Select]
$ 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!
 

Re: runit still doesn't work

Reply #9 –
Redirect the ssh-cat output to a file.

Re: runit still doesn't work

Reply #10 –
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.

Re: runit still doesn't work

Reply #11 –
Quote from: ####### – on
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.

Re: runit still doesn't work

Reply #12 –
Quote from: Dudemanguy – on
Redirect the ssh-cat output to a file.
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.
Code: [Select]
$ 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 
$
Code: [Select]
$ 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 
$
Code: [Select]
$ 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...

Re: runit still doesn't work

Reply #13 –
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
Code: [Select]
#!/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.
Code: [Select]
$ sudo cat /etc/runit/sv/ssh-chat/supervise/pid
798
Just read that file into a variable, kill $variable...

Re: runit still doesn't work

Reply #14 –
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.
Code: [Select]
$ 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.
Code: [Select]
$ 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
Code: [Select]
$ 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.