~sircmpwn/aerc

9 2

Re: mailto:... don't start composer

Jonas Müller
Details
Message ID
<C94TLKWRXWVZ.21DRUAXTIYKG4@tiggercloud>
DKIM signature
pass
Download raw message
I ran into the same problem a couple of days ago, see
https://todo.sr.ht/~sircmpwn/aerc2/480.

TL;DR: Aerc can't write to /run/user/xxxx/. Fix by setting
$XDG_RUNTIME_DIR to something your user has +w to, such as /tmp.

Re: mailto:... don't start composer

Details
Message ID
<7313478D-7CAE-4B2C-BEFD-79C8C5A6D867@labrat.space>
In-Reply-To
<C94TLKWRXWVZ.21DRUAXTIYKG4@tiggercloud> (view parent)
DKIM signature
pass
Download raw message
On 9 February 2021 08:26:55 CET, "Jonas Müller" <jonas-mueller@mailbox.org> wrote:
>TL;DR: Aerc can't write to /run/user/xxxx/. Fix by setting
>$XDG_RUNTIME_DIR to something your user has +w to, such as /tmp.

It doesn't make sense to have a non writable $XDG_RUNTIME_DIR. Its only purpose is being a scratch space for applications during runtime.

>$XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-essential runtime files and other file objects (such as sockets, named pipes, ...) should be stored.
>The directory MUST be owned by the user, and he MUST be the only one having read and write access to it.
>Its Unix access mode MUST be 0700.

If it is unset (and it really shouldn't be, systemd sets it and else whatever session manager you use is responsible for it) we fallback to /run/$UID/.

What distro do you use and in which configuration?

Re: mailto:... don't start composer

Jonas Müller
Details
Message ID
<C94WL3YACFFR.2Z6Q67IR5B6DT@tiggercloud>
In-Reply-To
<7313478D-7CAE-4B2C-BEFD-79C8C5A6D867@labrat.space> (view parent)
DKIM signature
pass
Download raw message
On Tue Feb 9, 2021, Reto wrote:
> It doesn't make sense to have a non writable $XDG_RUNTIME_DIR. Its only
> purpose is being a scratch space for applications during runtime.
Exactly :)

> If it is unset (and it really shouldn't be, systemd sets it and else
> whatever session manager you use is responsible for it) we fallback to
> /run/$UID/.
Not quite - if I unset $XDG_RUNTIME_DIR, my aerc tries /run/user/$UID/
(which may not exist). See log:

      2021/02/09 09:46:10 Starting up aerc
      [...]
      2021/02/09 09:46:10 Failed to start Unix server: listen unix /run/user/1001/aerc.sock: bind: no such file or directory (non-fatal)
      [...]

> What distro do you use and in which configuration?
Alpine 3.13.1

Re: mailto:... don't start composer

Details
Message ID
<755BFBBA-EF3A-481B-BBCC-AEF91A0DC1A2@labrat.space>
In-Reply-To
<C94WL3YACFFR.2Z6Q67IR5B6DT@tiggercloud> (view parent)
DKIM signature
pass
Download raw message
On 9 February 2021 10:47:21 CET, "Jonas Müller" <jonas-mueller@mailbox.org> wrote:
>> we fallback to /run/$UID/.
>Not quite - if I unset $XDG_RUNTIME_DIR, my aerc tries /run/user/$UID/
>(which may not exist). See log:

Yes, messed up the path in my reply, should have copy pasted from the docs instead of paraphrasing.

>> What distro do you use and in which configuration?
>Alpine 3.13.1

Heh, that's what you get from running a special snowflake distro ;P

Jokes aside, not sure how to best handle this. If we weren't given a proper dir to store the socket we could fallback to /tmp but I don't really like that.
I'd rather shift the problem to the users running a non standard setup.

We should provide a more meaningful error message though.

So you don't run a session manager at all?

Cheers,
Reto

Re: mailto:... don't start composer

Jonas Müller
Details
Message ID
<C94YLD7FEVMJ.30THKGQK02Q7F@tiggercloud>
In-Reply-To
<755BFBBA-EF3A-481B-BBCC-AEF91A0DC1A2@labrat.space> (view parent)
DKIM signature
pass
Download raw message
On Tue Feb 9, 2021, Reto wrote:
> Jokes aside, not sure how to best handle this. If we weren't given a
> proper dir to store the socket we could fallback to /tmp but I don't
> really like that.
> I'd rather shift the problem to the users running a non standard setup.
>
> We should provide a more meaningful error message though.
I agree. A better error message would be helpful ("Could not find
XDG_RUNTIME_DIR, using /run/user/xxxx/ instead"), but as I mentioned in
https://todo.sr.ht/~sircmpwn/aerc2/480, I don't understand why aerc
refuses to procress the `Mailto` when it's unable to start the server.

It could just as well proceed with composing the message - if the user
launches a second command `aerc mailto:foo@bar.com` and wonders why it
opens in his current shell rather than the already running aerc, the log
would show that aerc was unable to connect to the server and proceeded
on its own.

> So you don't run a session manager at all?
No, currently not.

Re: mailto:... don't start composer

Details
Message ID
<FE91AA81-AD5C-499C-ABF0-8A03CE9D5CA4@labrat.space>
In-Reply-To
<C94YLD7FEVMJ.30THKGQK02Q7F@tiggercloud> (view parent)
DKIM signature
pass
Download raw message
On 9 February 2021 12:21:44 CET, "Jonas Müller" <jonas-mueller@mailbox.org> wrote:
>https://todo.sr.ht/~sircmpwn/aerc2/480, I don't understand why aerc
>refuses to procress the `Mailto` when it's unable to start the server.

Because the way it works is that we start aerc and then re-inject the mailto command over the socket.

https://git.labrat.space/aerc/tree/aerc.go#n124

So we assume that the socket can be created and use it to talk to ourselves. Makes the code easy.
Failure to communicate is expected to be "no other aerc exists yet, we are the first".
Was introduced in
https://git.labrat.space/aerc/commit/aerc.go?id=f15811a737ee8d93f22ceff620df145c2d252b15

>It could just as well proceed with composing the message - if the user
>launches a second command `aerc mailto:foo@bar.com` and wonders why it
>opens in his current shell rather than the already running aerc, the
>log
>would show that aerc was unable to connect to the server and proceeded
>on its own.

Sure, feel free to send a patch doing that, I'm not opposed to it.
You just need to take care that you finish the startup of aerc prior to starting the composer as you need a selected account.

Re: mailto:... don't start composer

Jonas Müller
Details
Message ID
<C958J3LKF9E0.DU919X5NB3XC@tigger-mp>
In-Reply-To
<FE91AA81-AD5C-499C-ABF0-8A03CE9D5CA4@labrat.space> (view parent)
DKIM signature
pass
Download raw message
On Tue Feb 9, 2021, Reto wrote:
> Because the way it works is that we start aerc and then re-inject the
> mailto command over the socket.
Ah, now I get it. The code around ./aerc.go:180 makes a lot more sense now
:)

Having understood that part, I propose the following behaviour:

* If aerc can't write its socket, the error message should include a
  mention of XDG_RUNTIME_DIR ("Have you set XDG_RUNTIME_DIR?")

* If aerc.Mailto is set and we can't open or write the socket, aerc
  should quit with the above mentioned error message rather than open
  the inbox.

What do you think? If like, I can prepare a patch.

Re: mailto:... don't start composer

Details
Message ID
<20210210083018.rhnow4iccs4ml5li@feather.localdomain>
In-Reply-To
<C958J3LKF9E0.DU919X5NB3XC@tigger-mp> (view parent)
DKIM signature
pass
Download raw message
On Tue, Feb 09, 2021 at 08:08:57PM +0100, Jonas Müller wrote:
> * If aerc can't write its socket, the error message should include a
>   mention of XDG_RUNTIME_DIR ("Have you set XDG_RUNTIME_DIR?")

I'd rather show "can't create socket in $path: $error"
Generally you shouldn't set XDG_RUNTIME_DIR at all as this is the job of the
session manager. If you really want to elaborate we can do so in one of the
manpages and point to there.

> * If aerc.Mailto is set and we can't open or write the socket, aerc
>   should quit with the above mentioned error message rather than open
>   the inbox.

Nah, we should just open the composer without talking over the socket.
This needs some restructuring of the code so that we don't duplicate the work.

Cheers,
Reto

Re: mailto:... don't start composer

Jonas Müller
Details
Message ID
<C95QEOURLD4Y.3NH0L9Z975WGN@tiggercloud>
In-Reply-To
<20210210083018.rhnow4iccs4ml5li@feather.localdomain> (view parent)
DKIM signature
pass
Download raw message
On Wed Feb 10, 2021, Reto wrote:
> I'd rather show "can't create socket in $path: $error"
> Generally you shouldn't set XDG_RUNTIME_DIR at all as this is the job of
> the
> session manager. If you really want to elaborate we can do so in one of
> the
> manpages and point to there.
Sure. But following your argument means aerc is not meant to run without
a session manager?

> Nah, we should just open the composer without talking over the socket.
> This needs some restructuring of the code so that we don't duplicate the
> work.
As you like. I would have done it differently - if the socket is a
integral part of the structure aerc relies on, then it's not wrong to
fail early in case that part isn't there in my opinion. The
restructuring is more involved than I understand the internals at the
moment.

Re: mailto:... don't start composer

Details
Message ID
<B60F1B77-FE36-416D-A18A-820C178AEFA9@labrat.space>
In-Reply-To
<C95QEOURLD4Y.3NH0L9Z975WGN@tiggercloud> (view parent)
DKIM signature
pass
Download raw message
On 10 February 2021 10:09:31 CET, "Jonas Müller" <jonas-mueller@mailbox.org> wrote:
>Sure. But following your argument means aerc is not meant to run
>without
>a session manager?


No, what I'm trying to say is that we expected a somewhat reasonable env.
We expect to be able to spawn sh, have a writable $home etc.
Now, we don't use fancy things, but I also don't want to actively point people in the wrong direction.
Setting XDG_RUNTIME_DIR is on 90%+ of the distros the wrong thing to do.
Is it on yours? Sure but that doesn't make it the default solution.

Meaning I'd rather see here's the error, figure it out (with a reasonable explanation about how aerc comes up with the path) than tell people "just set this magic thing and it may work"

>As you like. I would have done it differently - if the socket is a
>integral part of the structure aerc relies on, then it's not wrong to
>fail early in case that part isn't there in my opinion. The
>restructuring is more involved than I understand the internals at the
>moment.

Except it isn't an integral part of aerc, hence the non fatal log if something goes wrong.
If aerc crashes it doesn't clean up the socket and then you wouldn't be able to restart aerc and that'd be bad.
Reply to thread Export thread (mbox)