supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Kelly Dean <kelly@prtime.org>
To: Laurent Bercot <ska-supervision@skarnet.org>
Cc: "supervision\@list.skarnet.org" <supervision@list.skarnet.org>
Subject: Re: s6 bites noob
Date: Tue, 05 Feb 2019 09:26:46 +0000	[thread overview]
Message-ID: <WV9ioBOpPZJIHA9mXPEV8rTZH75FDrrDvd9FhIZHICx@local> (raw)
In-Reply-To: <embbe8b262-3798-4f1d-b3ee-c2066203a749@elzian>


Laurent Bercot writes:
>>Anyway, recompile with -u 1000, re-update, and try again. Now, I can't even do s6-rc -a list; I get:
>>s6-rc fatal: unable to take locks: Permission denied
>
> Hmmm, that's weird. If all the previous operations have been done as
> the same user, you should never get EPERM. Have you run something as
> root before?

Indeed, I did. My command history from last night shows that before I remembered to try compiling with -u 1000, I tried sudo s6-rc change testpipe, after the previous non-sudo invocation failed with a permission error, so that must be what screwed it up. I don't remember doing that. Must have been really tired and frustrated.

So I killed svscan, removed my compiled databases and scan and live dirs, and started from scratch. Now s6-rc succeeds, but when I brought up testpipe (two daemons funneling to a logger), I got once per second:
fdclose: fatal: unable to exec ./run.user: Exec format error

Oops, I forgot #!/bin/bash at the top of one of the run files. (Would have been helpful if the error message had specified which one.) Fix that, recompile, make new link, do an update, try again. Now:
s6-fdholder-retrievec: fatal: unable to retrieve fd for id pipe:s6rc-r-logger: Broken pipe
s6-fdholder-retrievec: fatal: unable to retrieve fd for id pipe:s6rc-w-logger: Broken pipe
s6-fdholder-retrievec: fatal: unable to retrieve fd for id pipe:s6rc-r-logger: Connection reset by peer
s6-fdholder-retrievec: fatal: unable to retrieve fd for id pipe:s6rc-w-logger: Connection reset by peer

It also somehow managed to hose the terminal in which svscan was running. As in, when I try to type in it, only a small percentage of the letters actually appear. Killed svscan, tried to reset the terminal, no luck. This is the first time I remember ever getting an un-resettable terminal. No problem, I can just kill the terminal, but... weird.

Oops, after I added the forgotten #!/bin/bash, I forgot -u 1000 again when I recompiled. So, the failure should be expected, but hosing the terminal? Really? And the error messages give no hint of what's actually wrong, unless you're familiar with the internal design of s6, which seems an excessive burden for a mere user. I guess I'm spoiled by modern C compilers, which have become excellent in the past few years at explaining in exquisite detail exactly in which way I'm currently being an idiot.

So, remove the compiled databases and scan directory, recompile with -u 1000, restart svscan, re-run s6-rc-init, try testpipe again, and... success! Wow, that was unexpected. I'd become conditioned to expect failure.

Ok now, quick, while I remember how to use s6, I'll install it into my project and make sure it works perfectly, so I never have to touch it again. There are other things I'd be curious to try with it too, but I shouldn't keep pestering you and the mailing list for unpaid tech support, so I guess just take this as a data sample for what can happen when a random noob tries to use s6.

BTW, your explanations of why things are designed the way they are were helpful for understanding the system. I recommend copying them into the docs.


  reply	other threads:[~2019-02-05  9:26 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-31 18:32 Kelly Dean
2019-01-31 18:46 ` Kelly Dean
2019-01-31 20:19 ` Laurent Bercot
2019-01-31 21:53   ` svscan --help Jonathan de Boyne Pollard
2019-02-01  0:36   ` s6 bites noob Laurent Bercot
2019-02-01  4:18     ` Kelly Dean
2019-02-01  5:27       ` Colin Booth
2019-02-01  5:29       ` Colin Booth
2019-02-03  8:53   ` Kelly Dean
2019-02-03 10:19     ` Laurent Bercot
2019-02-04  7:42       ` Kelly Dean
2019-02-04 13:52         ` Laurent Bercot
2019-02-05  9:26           ` Kelly Dean [this message]
2019-02-05 19:44             ` Laurent Bercot
2019-02-03 10:39     ` svscan and supervise Jonathan de Boyne Pollard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=WV9ioBOpPZJIHA9mXPEV8rTZH75FDrrDvd9FhIZHICx@local \
    --to=kelly@prtime.org \
    --cc=ska-supervision@skarnet.org \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).