Bug 1888447 - Loses track of the current working directory because it doesn't know about static and transient hostnames
Summary: Loses track of the current working directory because it doesn't know about st...
Keywords:
Status: CLOSED DUPLICATE of bug 1893417
Alias: None
Product: Fedora
Classification: Fedora
Component: tilix
Version: 35
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kalev Lember
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1903092 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-10-14 21:24 UTC by smurfendrek123
Modified: 2022-12-05 21:03 UTC (History)
11 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2022-12-05 21:03:58 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github gnunn1 tilix issues 1954 0 None open Fedora 33 : vte configuration fixes no longer work. 2021-02-06 00:15:12 UTC

Description smurfendrek123 2020-10-14 21:24:25 UTC
When creating a new tile in tilix, the working directory is ~ instead of the directory of the previously focused tile. This used to work correctly on fedora 32.

I have tried both fixes outlined here: https://gnunn1.github.io/tilix-web/manual/vteconfig/

Comment 1 Kalev Lember 2020-10-14 21:52:10 UTC
Ah hm, I would guess it has something to do with newer vte291 in Fedora 33.

Comment 2 smurfendrek123 2020-10-28 18:51:30 UTC
Related github issue: https://github.com/gnunn1/tilix/issues/1954

Comment 3 Kalev Lember 2020-10-28 20:19:18 UTC
rishi, do you have any idea what's going wrong here?

Comment 4 smurfendrek123 2020-11-02 11:12:59 UTC
For those looking to get back to happily tiling for now, the following .tmux.conf (place that in your home directory) emulated my tilix use case pretty well. You can configure tilix (& other terminals) to start tmux directly when you open the terminal.

bind -n M-d split-window -c "#{pane_current_path}"
bind -n M-r split-window -h -c "#{pane_current_path}"
bind -n M-c new-window -c "#{pane_current_path}"
bind -n M-down select-pane -D
bind -n M-up select-pane -U
bind -n M-left select-pane -L
bind -n M-right select-pane -R

Comment 5 smurfendrek123 2020-11-02 17:51:40 UTC
This is also broken in kitty, so should this bug be filed against vte.sh instead of tilix? Can this report be changed, or do i need to make a new one?

Comment 6 smurfendrek123 2020-11-02 17:53:01 UTC
I changed the component to vte, hope that's allowed.

Comment 7 Kalev Lember 2020-11-02 18:58:35 UTC
Tilix uses vte291, moving to there.

Comment 8 Milan Zink 2020-11-03 20:21:34 UTC
Fish shell seems to work fine in tilix. Gnome-terminal new tab also switches to working dir, not ~.

Tilix reports vte config issues even if /etc/profile.d/vte.sh is sourced in .bashrc.

Comment 9 smurfendrek123 2020-11-11 15:16:30 UTC
Unlike kitty and tilix, splitting functionality still works as expected when using terminator, so it's still somehow possible to remember the previous directory.

Comment 10 Debarshi Ray 2020-11-11 16:50:44 UTC
For cases where the current working directory isn't getting preserved, what's the output of:
$ echo $PROMPT_COMMAND

Comment 11 smurfendrek123 2020-11-11 21:19:27 UTC
From tilix:

~ : echo $PROMPT_COMMAND 
__vte_prompt_command


Note that despite remembering the directory working correctly in terminator, the output of 'echo $PROMPT_COMMAND' is exactly the same in terminator.

Comment 12 Milan Zink 2020-11-12 09:38:03 UTC
This is very weird.. I've installed a new F33 virtual machine (+ dnf update) and it works out-of-the box in all mentioned terminal apps - tilix, gnome-terminal, terminator... 

echo $PROMPT_COMMAND gives the same results __vte_prompt_command.

/etc/profile.d/vte.sh seems to be sourced by default. No need to add it in .bashrc

Not able to reproduce it again.

Comment 13 Debarshi Ray 2020-11-12 17:35:16 UTC
I just installed Tilix on a freshly installed Fedora 33.

When I first started it, I got the dialog warning about the configuration problem, but after I clicked it away, Tilix was still able to preserve the current working directory. Then, once I closed Tilix, subsequent instances of the application don't show me the warning anymore, even though I didn't do anything to fix it.

Looking at tilix/source/gx/tilix/terminal/terminal.d, I see this condition for showing the warning dialog:
    if (terminalInitialized
        && tilix.testVTEConfig()
        && gst.currentLocalDirectory.length == 0
        && _overrideCommand.length == 0) {
        ...
        ...
        ...
    }

It seems to that the "gst.currentLocalDirectory.length == 0" is the main condition here, because the rest are just checking the state of the application so that the warning is shown only once during the lifetime of the application and at the right moment. However, it's not obvious to me that the condition is correct. Especially, since I received what seemed like a spurious warning.

I am also beginning to wonder if it could actually be a Tilix bug. I personally use GNOME Terminal, and I haven't hit any instance of the current working directory not being preserved, and it also looks like other VTE-based applications are working as expected.

Maybe Gerald would be able to shed some light on this, because my knowledge of D is zero.

Comment 14 smurfendrek123 2020-11-12 19:25:09 UTC
> I am also beginning to wonder if it could actually be a Tilix bug.

This could certainly be possible, but note that it is also broken in kitty (if correctly configured Kitty that is).

Comment 15 Gerald Nunn 2020-11-12 19:40:54 UTC
To preserve the working directory VTE requires that you have vte.sh hooked into bash either through your profile or some other mechanism. Not all Linux distros include vte.sh by default with Ubuntu being one of the main PAST offenders so this detection was an attempt on my part to proactively notify the user. It's not 100% accurate hence why there is a checkbox to ignore it.

In general if gnome-terminal works with regards to preserving the working directory then Tilix should work as well.

Note also I am no longer actively maintaining Tilix due to my other work commitments at Red Hat.

Comment 16 Milan Zink 2020-11-19 10:33:59 UTC
Hi All,

the problem is with hostname. Please check:

* https://github.com/gnunn1/tilix/issues/1954#issuecomment-730191381
* https://github.com/gnunn1/tilix/issues/1954#issuecomment-730279428

Comment 17 Kalev Lember 2020-12-01 11:32:07 UTC
*** Bug 1903092 has been marked as a duplicate of this bug. ***

Comment 18 Debarshi Ray 2021-05-20 23:19:37 UTC
On a freshly installed Fedora 33 Workstation:
```
[rishi@localhost ~]$ hostnamectl --transient 
fedora
[rishi@localhost ~]$ hostnamectl
   Static hostname: localhost.localdomain
Transient hostname: fedora
         Icon name: computer-vm
           Chassis: vm
        Machine ID: 7ff908d3de7a4f2da32c1ea976e103c2
           Boot ID: 932f0934cfa94a849bef6d8d01450e2e
    Virtualization: kvm
  Operating System: Fedora 33 (Workstation Edition)
       CPE OS Name: cpe:/o:fedoraproject:fedora:33
            Kernel: Linux 5.8.15-301.fc33.x86_64
      Architecture: x86-64
```

It turns out that the static and transient hostnames are set to different values. While the Bash prompt uses the static hostname, the mechanism to track the current working directory in `/etc/profile.d/vte.sh` uses the transient value through the `HOSTNAME` environment variable.

Under such circumstances, Tilix is indeed unable to track the current working directory and opens new terminals in `$HOME`, but GNOME Terminal somehow manages to keep tracking successfully. It looks like the two applications have some subtly different assumptions in the code, and it's possible that Tilix might have bet on the wrong horse.

Comment 19 Debarshi Ray 2021-05-21 22:52:20 UTC
The problem lies in Tilix's GlobalTerminalState class.

Tilix uses the hostname component of the current directory URI (eg., file://<hostname/path/to/directory) to differentiate between local and remote hosts. However, it uses gethostname(2) to get the local hostname which isn't able to differentiate between transient and static hostnames. So, in case, those are different, it gets confused and mistakes the local path as remote.

I'd suggest using systemd-hostnamed to query the local hostname. Specifically the /org/freedesktop/hostname1 D-Bus object on the org.freedesktop.hostname1 system service implements the org.freedesktop.hostname1 D-Bus interface that offers the Hostname (or the transient hostname) and StaticHostname properties.

gethostname could still be kept as a fallback for OSes without systemd-hostnamed.

Comment 20 Debarshi Ray 2021-05-21 22:53:12 UTC
GNOME Terminal doesn't try to differentiate between local and remote hosts, which is why it doesn't hit this problem.

Comment 21 Petr Sklenar 2021-08-02 11:08:35 UTC
as workaround I added into
/etc/profile.d/vte.sh

this:

HOSTNAME=$(/usr/bin/hostnamectl --static 2>/dev/null) || \
HOSTNAME=$(/usr/bin/hostname 2>/dev/null) || \
HOSTNAME=$(/usr/bin/uname -n)


and it seems to be working fine

Comment 22 Ben Cotton 2021-08-10 12:48:43 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.

Comment 23 Ben Cotton 2022-11-29 16:49:51 UTC
This message is a reminder that Fedora Linux 35 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '35'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 35 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 24 Debarshi Ray 2022-12-05 21:02:35 UTC
I believe this got fixed in Fedora 34.

Until Fedora 33, there were a lot of oddities in how the hostname got set in a default installation of Fedora Silverblue and Workstation, before the user went and explicitly set one statically (through Settings, for example).

Anaconda put localhost.localdomain in /etc/hostname, and systemd would try to smartly dodge that value as not a static hostname set by the user and fallback to a transient hostname obtained through DHCP or the hard-coded fallback hostname of 'fedora'.

Unfortunately, those 'smarts' in systemd weren't smart enough, and it got it wrong in some cases.  For example, it would still call sethostname(2) with localhost.localdomain from /etc/hostname to set the hostname in the kernel when booting.  Of course, the kernel doesn't know about static, transient and fallback hostnames.  So, commands like hostname(1) and 'uname --nodename' or the uname(2) system call would return localhost.localdomain, while 'hostnamectl hostname --transient' would return 'fedora'.

[Note that, with the GNU C Library, the gethostname(2) system call is implemented in terms of uname(2).]

This is why, on a freshly installed Fedora Silverblue or Workstation 33, the hostname in the Bash prompt and GNOME Terminal's (and also Tilix's?) headerbar didn't match.  The former used uname(2) and shortened it to 'localhost', while the latter used 'hostnamectl --transient' and got 'fedora'.  This in turn broke Tilix's logic to differentiate between local and remote hosts, and led to this bug.

All this got straightened out in Fedora 34.

Anaconda no longer puts localhost.localdomain in /etc/hostname on its own.  /etc/hostname is empty unless the user goes and explicitly sets a static hostname (through Settings, for example).  systemd no longer tries to special case localhost.localdomain.  It simply assumes that if /etc/hostname has something, then it's the static hostname, else there's no static hostname.

See bug 1893417 , and the upstream Anaconda and systemd pull requests linked from it, for the full details.

So, this is how it looks like on Fedora 34 Silverblue:

[rishi@fedora ~]$ cat /etc/hostname

[rishi@fedora ~]$ hostname
fedora
[rishi@fedora ~]$ uname -n
fedora
[rishi@fedora ~]$ hostnamectl --transient 
fedora
[rishi@fedora ~]$ echo $HOSTNAME
fedora
[rishi@fedora ~]$ hostnamectl status
   Static hostname: n/a                                                         
Transient hostname: fedora
         Icon name: computer-vm
           Chassis: vm
        Machine ID: 9c5968e4a24c4f2088419cd01fa1950b
           Boot ID: b7502d0268f94c4cba91889ea1c46ace
    Virtualization: qemu
  Operating System: Fedora 34.20210423.n.0 (Sil…
       CPE OS Name: cpe:/o:fedoraproject:fedora:34
            Kernel: Linux 5.11.12-300.fc34.x86_64
      Architecture: x86-64
   Hardware Vendor: QEMU
    Hardware Model: Standard PC _Q35 + ICH9, 2009_
[rishi@fedora ~]$ 

Compare this to comment 18 about Fedora 33 Workstation where the static hostname is set to localhost.localdomain, and got Tilix confused.

Comment 25 Debarshi Ray 2022-12-05 21:03:58 UTC

*** This bug has been marked as a duplicate of bug 1893417 ***


Note You need to log in before you can comment on or make changes to this bug.