[urbit] pormev-tagyln hosed again

[Paul Driver]

I don't know what happened this time, but now when I try to start
pormev-taglyn it tells me that egz.hope is corrupt. I did reboot the
machine (soft-reboot, not power cycle) without shutting down urbit first,
could that have anything to do with it? The urbit hasn't done anything else
since I got it back yesterday but hang out in :talk very briefly.

Anyways, here's a tarball.

https://www.dropbox.com/s/5hcjl2zqxma0pwk/pormev-taglyn-corrupt-egz.tar.gz?dl=1

[Curtis Yarvin]

Yeah, sorry, we can't fix this one! There is some kind of fsync issue with the current event log. We have a new code base that wants to be swapped in, and the eventual solution is a real log daemon, Kafka.

Tell us what platform you were on and email ***@tlon.io for a new planet. Sorry!

Sent from my iPhone

I don't know what happened this time, but now when I try to start pormev-taglyn it tells me that egz.hope is corrupt. I did reboot the machine (soft-reboot, not power cycle) without shutting down urbit first, could that have anything to do with it? The urbit hasn't done anything else since I got it back yesterday but hang out in :talk very briefly.
Anyways, here's a tarball.
https://www.dropbox.com/s/5hcjl2zqxma0pwk/pormev-taglyn-corrupt-egz.tar.gz?dl=1
--
You received this message because you are subscribed to the Google Groups "urbit" group.
For more options, visit https://groups.google.com/d/optout.

[Paul Driver]

No worries. x86_64 GNU/Linux (archlinux)

Post by Paul Driver
I don't know what happened this time, but now when I try to start
pormev-taglyn it tells me that egz.hope is corrupt. I did reboot the
machine (soft-reboot, not power cycle) without shutting down urbit first,
could that have anything to do with it? The urbit hasn't done anything else
since I got it back yesterday but hang out in :talk very briefly.
Anyways, here's a tarball.
https://www.dropbox.com/s/5hcjl2zqxma0pwk/pormev-taglyn-corrupt-egz.tar.gz?dl=1

[Galen Wolfe-Pauly]

Do we have an issue for this?

I’d make one, but I want to reference the actual crash message.

Post by Paul Driver
No worries. x86_64 GNU/Linux (archlinux)
I don't know what happened this time, but now when I try to start pormev-taglyn it tells me that egz.hope is corrupt. I did reboot the machine (soft-reboot, not power cycle) without shutting down urbit first, could that have anything to do with it? The urbit hasn't done anything else since I got it back yesterday but hang out in :talk very briefly.
Anyways, here's a tarball.
https://www.dropbox.com/s/5hcjl2zqxma0pwk/pormev-taglyn-corrupt-egz.tar.gz?dl=1 <https://www.dropbox.com/s/5hcjl2zqxma0pwk/pormev-taglyn-corrupt-egz.tar.gz?dl=1>
--
You received this message because you are subscribed to the Google Groups "urbit" group.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

[Curtis Yarvin]

I don't think so. And I think a description of the problem is sufficient in this case... it's not like there are or can be predictable repro steps.

Sent from my iPhone

Post by Galen Wolfe-Pauly
Do we have an issue for this?
I’d make one, but I want to reference the actual crash message.

Post by Paul Driver
No worries. x86_64 GNU/Linux (archlinux)

I don't know what happened this time, but now when I try to start pormev-taglyn it tells me that egz.hope is corrupt. I did reboot the machine (soft-reboot, not power cycle) without shutting down urbit first, could that have anything to do with it? The urbit hasn't done anything else since I got it back yesterday but hang out in :talk very briefly.
Anyways, here's a tarball.
https://www.dropbox.com/s/5hcjl2zqxma0pwk/pormev-taglyn-corrupt-egz.tar.gz?dl=1

--
You received this message because you are subscribed to the Google Groups "urbit" group.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "urbit" group.
For more options, visit https://groups.google.com/d/optout.

[Galen Wolfe-Pauly]

Right — just want to be able to point at something and say ‘this thing!’

What was the final death-rattle-printf of pormev?

Post by Curtis Yarvin
I don't think so. And I think a description of the problem is sufficient in this case... it's not like there are or can be predictable repro steps.
Sent from my iPhone

Post by Galen Wolfe-Pauly
Do we have an issue for this?
I’d make one, but I want to reference the actual crash message.

Post by Paul Driver
No worries. x86_64 GNU/Linux (archlinux)
I don't know what happened this time, but now when I try to start pormev-taglyn it tells me that egz.hope is corrupt. I did reboot the machine (soft-reboot, not power cycle) without shutting down urbit first, could that have anything to do with it? The urbit hasn't done anything else since I got it back yesterday but hang out in :talk very briefly.
Anyways, here's a tarball.
https://www.dropbox.com/s/5hcjl2zqxma0pwk/pormev-taglyn-corrupt-egz.tar.gz?dl=1 <https://www.dropbox.com/s/5hcjl2zqxma0pwk/pormev-taglyn-corrupt-egz.tar.gz?dl=1>
--
You received this message because you are subscribed to the Google Groups "urbit" group.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

--
You received this message because you are subscribed to the Google Groups "urbit" group.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

[Anton Dyudin]

Well, "ctrl-z the pier a bunch" seems fairly reliable in causing it, at
least on Mac.

Post by Galen Wolfe-Pauly
Right — just want to be able to point at something and say ‘this thing!’
What was the final death-rattle-printf of pormev?
I don't think so. And I think a description of the problem is sufficient
in this case... it's not like there are or can be predictable repro steps.
Sent from my iPhone
Do we have an issue for this?
I’d make one, but I want to reference the actual crash message.
No worries. x86_64 GNU/Linux (archlinux)

Post by Paul Driver
I don't know what happened this time, but now when I try to start
pormev-taglyn it tells me that egz.hope is corrupt. I did reboot the
machine (soft-reboot, not power cycle) without shutting down urbit first,
could that have anything to do with it? The urbit hasn't done anything else
since I got it back yesterday but hang out in :talk very briefly.
Anyways, here's a tarball.
https://www.dropbox.com/s/5hcjl2zqxma0pwk/pormev-taglyn-corrupt-egz.tar.gz?dl=1

--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
.
For more options, visit https://groups.google.com/d/optout.

[Curtis Yarvin]

Ctrl-z does horrible, horrible things to our fragile tty state as
well. Avoid. (Actually I think we can set the tty to disable it...)

Post by Anton Dyudin
Well, "ctrl-z the pier a bunch" seems fairly reliable in causing it, at
least on Mac.

Right — just want to be able to point at something and say ‘this thing!’
What was the final death-rattle-printf of pormev?
I don't think so. And I think a description of the problem is sufficient
in this case... it's not like there are or can be predictable repro steps.
Sent from my iPhone
Do we have an issue for this?
I’d make one, but I want to reference the actual crash message.
No worries. x86_64 GNU/Linux (archlinux)

Post by Paul Driver
I don't know what happened this time, but now when I try to start
pormev-taglyn it tells me that egz.hope is corrupt. I did reboot the machine
(soft-reboot, not power cycle) without shutting down urbit first, could that
have anything to do with it? The urbit hasn't done anything else since I got
it back yesterday but hang out in :talk very briefly.
Anyways, here's a tarball.
https://www.dropbox.com/s/5hcjl2zqxma0pwk/pormev-taglyn-corrupt-egz.tar.gz?dl=1

--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Anton Dyudin]

Repeated ctrl-z followed by kill -9, to be specific, which is the "I'm not
going to /tell/ the process there wasn't an unscheduled powerdown" option.

And nope, not allowed, making use of that option on anything that can hang
for more than ~50ms violates the User Control maxim of interaction
design ^-^

Post by Curtis Yarvin
Ctrl-z does horrible, horrible things to our fragile tty state as
well. Avoid. (Actually I think we can set the tty to disable it...)

Post by Anton Dyudin
Well, "ctrl-z the pier a bunch" seems fairly reliable in causing it, at
least on Mac.

Post by Galen Wolfe-Pauly
Right — just want to be able to point at something and say ‘this thing!’
What was the final death-rattle-printf of pormev?
I don't think so. And I think a description of the problem is

sufficient

Post by Anton Dyudin

Post by Galen Wolfe-Pauly
in this case... it's not like there are or can be predictable repro

steps.

Post by Anton Dyudin

Post by Galen Wolfe-Pauly
Sent from my iPhone
Do we have an issue for this?
I’d make one, but I want to reference the actual crash message.
No worries. x86_64 GNU/Linux (archlinux)

Post by Paul Driver
I don't know what happened this time, but now when I try to start
pormev-taglyn it tells me that egz.hope is corrupt. I did reboot the

machine

Post by Anton Dyudin

Post by Galen Wolfe-Pauly

Post by Paul Driver
(soft-reboot, not power cycle) without shutting down urbit first,

could that

Post by Anton Dyudin

Post by Galen Wolfe-Pauly

Post by Paul Driver
have anything to do with it? The urbit hasn't done anything else since

I got

Post by Anton Dyudin

Post by Galen Wolfe-Pauly

Post by Paul Driver
it back yesterday but hang out in :talk very briefly.
Anyways, here's a tarball.

https://www.dropbox.com/s/5hcjl2zqxma0pwk/pormev-taglyn-corrupt-egz.tar.gz?dl=1

Post by Anton Dyudin

Post by Galen Wolfe-Pauly
--
You received this message because you are subscribed to the Google

Groups

Post by Anton Dyudin

Post by Galen Wolfe-Pauly
"urbit" group.
To unsubscribe from this group and stop receiving emails from it, send

an
<javascript:;>.

Post by Anton Dyudin

Post by Galen Wolfe-Pauly
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google

Groups

Post by Anton Dyudin

Post by Galen Wolfe-Pauly
"urbit" group.
To unsubscribe from this group and stop receiving emails from it, send

an
<javascript:;>.

Post by Anton Dyudin

Post by Galen Wolfe-Pauly
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google

Groups

Post by Anton Dyudin

Post by Galen Wolfe-Pauly
"urbit" group.
To unsubscribe from this group and stop receiving emails from it, send

an
<javascript:;>.

Post by Anton Dyudin

Post by Galen Wolfe-Pauly
For more options, visit https://groups.google.com/d/optout.

[Raymond Pasco]

Someone mentioned a patch to catch and ignore terminal stop, but I don't
think I ever saw the actual patch materialize.

Yours,
r

[Anton Dyudin]

Fwiw, if I saw that in third-party software(other than like screen or a
shell or such whose alternate exit commands are responsive), I'd probably
at least try to write a wrapper that sent actual SIGSTOP instead of SIGSTP

Ultimately, urbit claims to handle kill9 fine, and should act accordingly.

Post by Raymond Pasco
Someone mentioned a patch to catch and ignore terminal stop, but I don't
think I ever saw the actual patch materialize.
Yours,
r

[Raymond Pasco]

You can do that, but it's your own Viking funeral, and I hope that you're
consistent and wrap all your urbit instances with something that traps ^C
and sends a sigkill, or at least a sigquit, to get around the sigint signal
handler as well...

For everyone else, there's signal handlers, and should you have an arcane
unixy reason to want to suspend vere (vanishingly unlikely), you can use the
kill(2) system call or one of its many conveniently precompiled frontends
that isn't a fat finger away to send an uncatchable sigstop, and have full
responsibility for the pier-hosings. But if someone hoses their pier with a
^Z that we don't catch, it's *our* fault it's hosed.

Yours,
r

[Anton Dyudin]

Signal handlers are meant to handle signals in ways appropriate to the
intentions/name of the signal. I would have zero issues with a ^Z handler
that actually paused ~something~ immediately returning control to the user;
"just drop it" is not reasonable handling however.

Post by Raymond Pasco
You can do that, but it's your own Viking funeral, and I hope that you're
consistent and wrap all your urbit instances with something that traps ^C
and sends a sigkill, or at least a sigquit, to get around the sigint signal
handler as well...
For everyone else, there's signal handlers, and should you have an arcane
unixy reason to want to suspend vere (vanishingly unlikely), you can use the
kill(2) system call or one of its many conveniently precompiled frontends
that isn't a fat finger away to send an uncatchable sigstop, and have full
responsibility for the pier-hosings. But if someone hoses their pier with a
^Z that we don't catch, it's *our* fault it's hosed.
Yours,
r
--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Raymond Pasco]

SIG_IGN (which is so valid a signal handler, it's actually a predefined
macro!) is about the only reasonable thing we can do with it, and I strain
to think of reasons that sigtstp even exists as its own signal that are not
"so it can be caught, unlike the uncatchable sigstop".

Google Code Search is dead, but type "signal(SIGTSTP, SIG_IGN)" into your
favorite alternative to see how far this particular horse is from the barn.
From the starting gate at Churchill Downs, rather, since this horse ran away
entirely by design. (No, SIGCRETARIAT is not a standard macro - it's over 7
characters, for one.)

I will certainly not lose any sleep over a 25-byte call to a standard
library function for its intended purpose and sparing users various
avoidable unixy catastrophes.

Yours,
r

[Anton Dyudin]

To reiterate, what is an alternate way to exit a pier in less than a
second? (I'm looking at you ^\)

Post by Raymond Pasco
SIG_IGN (which is so valid a signal handler, it's actually a predefined
macro!) is about the only reasonable thing we can do with it, and I strain
to think of reasons that sigtstp even exists as its own signal that are not
"so it can be caught, unlike the uncatchable sigstop".
Google Code Search is dead, but type "signal(SIGTSTP, SIG_IGN)" into your
favorite alternative to see how far this particular horse is from the barn.
From the starting gate at Churchill Downs, rather, since this horse ran away
entirely by design. (No, SIGCRETARIAT is not a standard macro - it's over 7
characters, for one.)
I will certainly not lose any sleep over a 25-byte call to a standard
library function for its intended purpose and sparing users various
avoidable unixy catastrophes.
Yours,
r

[Anton Dyudin]

Also, I could totally see "stop current event, dropping into a dojo prompt
that can have no event log side effects, except a "fg" equivalent and
"kill" which drops it and re-enables networking etc." Indeed,
urbit-as-a-shell does approximately this with SIGINT, mostly.
And yes, the things I've encountered that have ^Z bound(screen,bash,
) all
passed it it through to some encompassed process. Which is an entirely
reasonable use case of catchable STP. (I admit my Unix experience is
limited re: processes refusing to be backgrounded).

Post by Anton Dyudin
To reiterate, what is an alternate way to exit a pier in less than a
second? (I'm looking at you ^\)

Post by Raymond Pasco
SIG_IGN (which is so valid a signal handler, it's actually a predefined
macro!) is about the only reasonable thing we can do with it, and I strain
to think of reasons that sigtstp even exists as its own signal that are not
"so it can be caught, unlike the uncatchable sigstop".
Google Code Search is dead, but type "signal(SIGTSTP, SIG_IGN)" into your
favorite alternative to see how far this particular horse is from the barn.
From the starting gate at Churchill Downs, rather, since this horse ran away
entirely by design. (No, SIGCRETARIAT is not a standard macro - it's over 7
characters, for one.)
I will certainly not lose any sleep over a 25-byte call to a standard
library function for its intended purpose and sparing users various
avoidable unixy catastrophes.
Yours,
r

[Raymond Pasco]

I am truly sorry that your workflow apparently involves suspending vere
processes that are not running inside a debugger, but I don't think that is
a good reason to not do something that is both helpful to users and really
utterly commonplace. Perhaps you should install GDB/LLDB, or screen/tmux/a
windowing environment if you just want a shell fast. If you just want them
dead, we helpfully deliberately don't trap SIGQUIT for just this case. If
you don't like that it makes core dumps, you can presumably set the maximum
core dump size in your session to 0 to prevent it.

Your shell certainly does not have a "pass through" handler or anything like
that, incidentally. That is not how terminal escapes or signals work at all.
Unless there's some really funky edge case I'm forgetting (and there may be
in the case of something like tmux), they will both probably SIG_IGN things
like SIGINT and SIGTSTP. It is the terminal driver that decides where
signals go and has to be told what the "foreground" is. (This is in your
shell's purview.)

Yours,
r

[Anton Dyudin]

My workflow invloves ^Zkill -9 %1 , because ^C^U^D does not work reliably,
and ^\ is for when I do want to wait around for a core dump.

All I know is that when I start e.g. cat in bash, ^Z does what you'd
expect, but for bash in bash, the ^Z is handled by the inner shell. Perhaps
this is accomplished by SIG_IGN followed by recieving the literal control
character; in any case, "just ignore it" definitely isn't the resulting UX,
but afaict is what you're proposing.

Post by Raymond Pasco
I am truly sorry that your workflow apparently involves suspending vere
processes that are not running inside a debugger, but I don't think that is
a good reason to not do something that is both helpful to users and really
utterly commonplace. Perhaps you should install GDB/LLDB, or screen/tmux/a
windowing environment if you just want a shell fast. If you just want them
dead, we helpfully deliberately don't trap SIGQUIT for just this case. If
you don't like that it makes core dumps, you can presumably set the maximum
core dump size in your session to 0 to prevent it.
Your shell certainly does not have a "pass through" handler or anything like
that, incidentally. That is not how terminal escapes or signals work at all.
Unless there's some really funky edge case I'm forgetting (and there may be
in the case of something like tmux), they will both probably SIG_IGN things
like SIGINT and SIGTSTP. It is the terminal driver that decides where
signals go and has to be told what the "foreground" is. (This is in your
shell's purview.)
Yours,
r

[Raymond Pasco]

There is a job control component in your shell that talks to the terminal
driver, via the ioctl(2) system call, and tells it where to send these sorts
of keyboard-generated signals. I find this man page to be an enlightening
overview of the concepts: https://www.freebsd.org/cgi/man.cgi?query=termios

You only get the raw characters if you totally disable the
signals-from-keyboard-interrupts functionality, or specifically set the
control character for one of them to be disabled, which is what Curtis
probably had in the back of his mind up the email chain. This is still
terminal driver functionality. See the above man page again for more
information.

Vere sets a rawer-than-average termios, but it is not in this sort of
full-on unadulterated raw mode, and makes use of signal handlers for
terminal-generated signals. (When people say "raw mode", they are
oversimplifying quite a bit.) The thing about handling the terminal directly
is that you will, by nature, not play well with others that want to use the
same terminal. This is why vere ends up in such a whacked-out state when
returning from a suspend. Fortunately, your state is your event log, so you
can just kill the damaged process and get a brand new one. To avoid getting
oneself or one's downstream users into this situation, one can do the
absolutely boring and standard thing and trap the signal, if one does not
have the time, capacity, or inclination to do the seriously annoying work of
making it work correctly. (I have a *very strong* inclination *against*
introducing anything even remotely close to screen clears into vere. We are
in a surprisingly happy place as far as terminal drivers go right now.)

Yours,
r

[Curtis Yarvin]

The correct solution is to make ^C^U^D actually work. The easiest
solution is to turn off ^Z by ignoring SIGTSTP, since I've seen bad
^Zs bollix quite a number of users.

Actually, I think Anton and Raymond would both be satisfied by
quitting on SIGTSTP, which is arguably proper behavior for a
persistent process. I'll submit this.

Post by Raymond Pasco
There is a job control component in your shell that talks to the terminal
driver, via the ioctl(2) system call, and tells it where to send these sorts
of keyboard-generated signals. I find this man page to be an enlightening
overview of the concepts: https://www.freebsd.org/cgi/man.cgi?query=termios
You only get the raw characters if you totally disable the
signals-from-keyboard-interrupts functionality, or specifically set the
control character for one of them to be disabled, which is what Curtis
probably had in the back of his mind up the email chain. This is still
terminal driver functionality. See the above man page again for more
information.
Vere sets a rawer-than-average termios, but it is not in this sort of
full-on unadulterated raw mode, and makes use of signal handlers for
terminal-generated signals. (When people say "raw mode", they are
oversimplifying quite a bit.) The thing about handling the terminal directly
is that you will, by nature, not play well with others that want to use the
same terminal. This is why vere ends up in such a whacked-out state when
returning from a suspend. Fortunately, your state is your event log, so you
can just kill the damaged process and get a brand new one. To avoid getting
oneself or one's downstream users into this situation, one can do the
absolutely boring and standard thing and trap the signal, if one does not
have the time, capacity, or inclination to do the seriously annoying work of
making it work correctly. (I have a *very strong* inclination *against*
introducing anything even remotely close to screen clears into vere. We are
in a surprisingly happy place as far as terminal drivers go right now.)
Yours,
r