aura
aura copied to clipboard
fosskers
Potential Permission Errors on "/tmp" -- preventing X from Starting
Since the last couple of fixes, especially the one related to permissions, I am getting failures to write to /tmp by several programs, not the least of which is related to xorg-xinit which is either unable to write /tmp/serverauth.* to /tmp causing X server to fail to start or the system being unable to automatically remove /tmp/serverauth.* when killing X on shutdown.
These errors are usually "resolved" by rebooting which is not a proper solution.
These errors could be completely unrelated to aura but somehow I have the feeling that the coincidence is too strong to be ignored.
As a reminder, I build from stack, in case it makes a difference.
Note: I see a few lines of code such as:
aura/lib/Aura/Build.hs: "/tmp" -> setMode "1777"
aura/lib/Aura/Install.hs: setCurrentDirectory "/tmp"
in the code but not sure how or if that could impact this issue.
Any chance you can look into it? Let me know how I can help.
Hi, @stef204
Did you look at #651, #661 and #663?
Also, the first thing to do in a bug report is to mention the version or git commit you were building from. :slightly_smiling_face:
If rebooting usually resolves these errors, then what permissions are on your /tmp at the moment of starting?
$ ls -ld /tmp
@ratijas
I've looked at all of the issues you mention as a frequent user of aura.
% stat /tmp
File: /tmp
Size: 640 Blocks: 0 IO Block: 4096 directory
Device: 2fh/47d Inode: 1 Links: 19
Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2020-11-05 13:52:52.834311537 -0500
Modify: 2020-11-05 12:53:36.571068583 -0500
Change: 2020-11-05 12:53:36.571068583 -0500
Birth: -
Let's have @fosskers chime in and see if any feedback.
So, it's just usual 1777 root:root at boot time, huh. And what happens to it after aura?
il looks the same, and the file /tmp/serverauth.* has 600 perms and is owned by $USER:users so should have no problem being deleted automatically when killing X.
Yet I get the permission error (paraphrasing): cannot remove /tmp/serverauth.* permission denied`.
This makes nosense.
On boot, on the other hand, when the error occurs, it cannot create the file /tmp/serverauth.* so X server cannot start.
That's when I need to reboot.
I think this occurs after I upgrade my box using pacman first and then aura; using the console.
Since this started at the same time as the fix for permission issue in aura, I am trying to troubleshoot if it comes from interaction between aura and /tmp.
As I said above, it may not be related but I cannot ignore it; trying to troubleshoot.
It wouldn't surprise me if these are side-effects of the latest patch. One other thing to try is to specify an alternate build directory with --build=/full/path/to/build/dir which could be, say, /home/<you>/aura/. This directory can also be set in an aura.conf. Then, if your /tmp issues get figured out, they should stay fixed even if you revert to using it as the default build dir.
A note on future policy: I think for Aura 4.0 we should be building in a ~/.aura/build/ instead and leave the parent filesystem alone. This will be much easier for users to manage.
A note on future policy: I think for Aura 4.0 we should be building in a ~/.aura/build/ instead and leave the parent filesystem alone. This will be much easier for users to manage.
No! For the love of God, don't pollute $HOME with yet another dot-trash. There's XDG specification about cache folder location. tl; dr: ${XDG_CACHE_HOME:-$HOME/.cache}/aura.
Yes that would work well too. Whatever is well understood and easy for users to clear if they need.
...and to avoid automatically backing up or even removing entirely when desperately need to reclaim some disk space.
It wouldn't surprise me if these are side-effects of the latest patch.
That's my feeling as well, side effect from the patch or fix.
One other thing to try is to specify an alternate build directory with
--build=/full/path/to/build/dirwhich could be, say,/home/<you>/aura/. This directory can also be set in anaura.conf. Then, if your/tmpissues get figured out, they should stay fixed even if you revert to using it as the default build dir.
I will set a build dir in aura.conf, use that and report back here.
A note on future policy: I think for Aura 4.0 we should be building in a
~/.aura/build/instead and leave the parent filesystem alone. This will be much easier for users to manage.
I agree with you here as well. This is preferred over touching /tmp.
I think that @ratijas comment re. $XDG_CACHE_HOME is on point.
@fosskers Where should aura.conf be located? ~ ? is it a dot file? No dots? Don't see anything in --help.
And what's the name of the value or variable? Format of file, etc,?
Either /etc/aura.conf or /home/you/.config/aura/aura.conf. I know you build from source, but otherwise you could man aura.conf for more info. Here's a template: https://github.com/fosskers/aura/blob/master/aura/doc/aura.conf
I've defined the build dir in aura.confas: ~/build/aura.
Of course, this is less convenient than /tmp as I would have to clean that dir manually, but I'm not too bothered by it.
So far so good, but I need to use it through a few more reboots, etc.
Incidentally, how would I build aura with stack and get the docs (man page)?
Incidentally, how would I build aura with stack and get the docs (man page)?
Usually, I just use PKGBUILD scripts from AUR. Works most of the time, and quite reproducible.
Incidentally, how would I build
aurawith stack and get the docs (man page)?
% sudo install -Dm644 aura/aura/doc/aura.8 /usr/share/man/man8/aura.8
and
sudo install -Dm644 aura.conf.5 /usr/share/man/man5/aura.conf.5
Anything else needed?
The above works but it's manual. Is there anything I can do at compile time to get this installed automatically when building with stack? (I mean besides using the aura-git package in AUR?
PS I guess I can write a script to build and install.....
@stef204
There's always a way, if you are a bit creative. But I think generally you don't want to overload your build system with unrelated tasks. stack is too busy building Haskell libs and binaries — and I'd wish to say it's doing well at least that much. There's a reason why npm scripts considered harmful by many.
@stef204 There's always a way, if you are a bit creative. But I think generally you don't want to overload your build system with unrelated tasks.
stackis too busy building Haskell libs and binaries — and I'd wish to say it's doing well at least that much. There's a reason whynpmscripts considered harmful by many.
I don't use npm. But I could write a bash scrip to build using stack and then install the man pages and zsh completions; that's literally "risk free".
I don't use npm. But I could write a bash scrip to build using stack and then install the man pages and zsh completions; that's literally "risk free".
That sounds like the least evil way to do it. While a truly "good way" would be to use the package manager provided by your OS. Besides, that's literally what PKGBUILD is doing — it's a bash script which calls stack and copies man pages etc.
@ratijas
Honestly, you;re adding nothing to the conversation. With due respect, I'd appreciate if you stayed off this thread. I'm really looking for feedback from the dev. Thanks.
Incidentally, how would I build aura with stack and get the docs (man page)?
Unfortunately there is no such official way, unless you install via aura-git as you mentioned. But note that I have no control over that package.
One thing you could also consider is setting a symlink in /usr/share/man/man8/ that points to the manpage stored in your clone of the repo (aura/aura/doc/aura.8).
One thing you could also consider is setting a symlink in
/usr/share/man/man8/that points to the manpage stored in your clone of the repo (aura/aura/doc/aura.8).
Yes, I could do that, same for the zsh completion. Good idea (better than the bash script.) Didn't think of it, thanks.