Until recently, I was able to use /usr/bin/write and /usr/bin/wall to send messages to users in xfce4-terminal sessions. This no longer works, even though the users' mesg setting is y. I also notice that xfce4-terminal sessions no longer appear in "who" output or produce any text at all when running "who am I". I'm not certain exactly when the change happened, but I did upgrade from xubuntu 16.10 to 17.04 recently, so it seems likely that the breakage came with the switch from xfce4-terminal 0.6.3 to 0.8.4. Help, please?
I notice that xfce4-terminal sessions no longer have a pts or appear in utmp. Maybe this is what caused the broken functionality?
xterm still handles this stuff correctly (but of course, xterm is less desirable than xfce4-terminal in other respects). I don't know what was changed in xfce4-terminal, but it clearly broke some things.
This must be related to vte - they have dropped utmp support since version 0.38. I've checked gnome-terminal and tilix (both vte-based) - and they are behaving the same way as xfce4-terminal. Egmont, could you please confirm my understanding?
Yup, see https://bugzilla.gnome.org/show_bug.cgi?id=747046.
Thanks Egmont. The bug record also has a link to another bug which is similar to this one but logged a few days earlier: https://bugzilla.redhat.com/show_bug.cgi?id=1466993 Egmont, do I understand correctly that you have no plans on restoring utmp support in vte? What about using libutempter which you've mentioned?
> Egmont, do I understand correctly that you have no plans on restoring utmp support in vte? Yup. > What about using libutempter which you've mentioned? Not planning this one either. I'll comment on the Red Hat bug as time permits (probably in a week or so).
Hi Forest, are you ok with the explanations above?
I comprehend the explanations above, but as a user, they are just excuses for the fact that someone decided to break a bunch of important functionality without any warning or any provision to replace it. The mesg, write, wall, who, and who am i commands are and have been standard unix commands for decades. People (including myself) depend on them for our systems to work properly. Now we are left having to give up xfce4-terminal (and every other terminal that depends on vte), apparently because someone upstream decided that simplifying their code is more important than having shell sessions that work correctly. So, I guess the burden now falls on the xfce4-terminal maintainers: Do you want your terminal to remain broken, or will you add the utmp functionality that was dropped by your upstream library? I'll go back to xterm if I have to, but it's so ugly and poorly-integrated into xfce that I hate the idea.
FYI, there are other components of unix-like systems that depend on the broken functionality as well. For example, warning messages sent to logged-in users when a system reboot or shutdown is impending.
Yes, I understand your problem as a user. I will into look making use of libutemper lib to bring back utmp support. Meanwhile, can using the following workaround mitigate the issue for you? You can `echo "test" > /dev/pts/xx` to send a message to a user.
Thank you, Igor. I really appreciate your attention here. And thanks for offering a workaround suggestion, but it won't work. Users are no longer getting a pts, so there is no /dev/pts/xx device that I can use to send them a message. (Also, even if there was, manually echoing messages to pts devices doesn't fix automated scripts that were broken by when write, wall, who, and the like stopped working.)
(In reply to Forest from comment #11) > And thanks for offering a workaround suggestion, but it won't work. Users > are no longer getting a pts, so there is no /dev/pts/xx device that I can > use to send them a message. Hmm, I can see a pts device for each xfce4-terminal tab in the Ubuntu 16.04 system I have here.
Oops... right you are. I didn't notice the device because I looked for it using "who", like I normally would. Okay, so that workaround can be used to manually send messages from a root user to other users' logged-in shells, but it doesn't help non-root users, and doesn't solve any of the other breakage.
I made a comment about my personal opinion in the GNOME bug.
(In reply to Egmont Koblinger from comment #14) > I made a comment about my personal opinion in the GNOME bug. That's an awesome text, Egmont, and I mean it! I think your arguments are totally valid.
I think Egmont and I agree on the background of this issue, all of which can be summarized by saying that the current utmp/mesg system is sub-optimal. Our disagreement lies in these two points: 1. I believe it is unreasonable to break a well-established piece of an operating environment that is used by many people for diverse tasks and workflows, before a suitable replacement is available. 2. I would not cite my own lack of need for a thing as justification for taking it away from other people who might be using it. In cases where it makes sense to move past dated technology, I suggest identifying an alternative and giving existing users, organizations, and systems a chance to migrate to it first, rather than abruptly cutting them off at the knees. In other words, please do not break working systems. I'm not sure what the jab about 1900's technology was supposed to do other than conjure up an emotional response to support an agenda, but for comparison, my neighborhood's water pipes, power lines, and sewer system are all 1900's technology or older. They're aging and fundamentally flawed and frequently problematic, but no reasonable person would simply rip them out without something to take their place, because people depend on them. Also, every unix-like operating system in the world (like the ones we're all using) is by definition 1900's technology; pointing out that they are older than a teenager is a poor assessment of their utility and a weak argument for throwing them out.
(In reply to Forest from comment #16) > 1. I believe it is unreasonable to break a well-established "well-established": See my comment on Ubuntu vs. "write". > 2. I would not cite my own lack of need It's not my lack of need, it's my (subjective and limited) observation about the directions computer systems have shifted towards. IMO relatively fewer setups where there could be a need for such messages, and even those setups probably maintained in a much more professional way than decades ago (like e.g. no sudden unscheduled reboot apart from a very few exceptional cases). I phrased it quite poorly though. > In other words, please do not break working systems. IMO we didn't. We smashed a hardly working one. > I'm not sure what the jab about 1900's technology was supposed to do In case it wasn't clear, in my opinion the UX where we 1) require the user to run a certain special kind of app that (s)he might not need at all, taking up quite a bit of screen real estate, just in order to receive messages, 2) a message corrupts the display of that app, and 3) the message is still not delivered anywhere close to reliably, is unacceptable in at least these three aspects. UX expectations have increased this much since the 1900's. You yourself say you're reluctant to switch to xterm because its look-n-feel doesn't match the rest of your system, so I'm not sure how you can be happy with this behavior. You're of course free to use whichever app you wish to, or file feature requests. You could even let's say keep an xterm in the corner of the screen to see notifications, and do the daily work in xfce4-terminal. Or use an ancient vte/xfce4-terminal combo. Or come up with a patch to either of these... or work towards (even if just by sending bugreports and e-mails) a proper notification system.
I've added an experimental support of libutempter - it's very simple, just adding an utmp record on starting a client and removing it on exiting. Forest, it would be awesome if you could test it. I'm not very familiar with the entire system and would like to be sure it's working properly. Though basic `write` and `wall` functionality seems to be working. The change is published in my github repo: https://github.com/f2404/xfce4-terminal3/commit/b4c410fa1f1f7fde4a630943e181f7d90a849ad9
Created attachment 7236 Enable utempter support unconditionally Derived from Igor's patch, applies to 0.8.6 sources, builds with utempter support automatically simply by applying the patch. Not trying to take any credit here at all - just providing something to make it a bit easier for folks to test. Tested successfully here with vte-0.48.3 -- nice to have wall working again; thanks, Igor!
Thanks Robby, I think your patch can indeed help others test the change.
Igor referenced this bugreport in commit 62dfc39954cef2b2c7649f874a27b38142ee855b Add a UI control whether to update utmp/wtmp records https://git.xfce.org/apps/xfce4-terminal/commit?id=62dfc39954cef2b2c7649f874a27b38142ee855b
I finally got round to adding a UI setting for this option. Having done that, I consider this bug fixed.
0.8.7 release? :-)
(In reply to Robby Workman from comment #23) > 0.8.7 release? :-) Soon :)
Thanks so much, Igor! Looks like the new feature is excluded from default builds, so it's unavailable in debian or ubuntu releases. I'll submit a request for the package maintainer to add --with-utempter in the future. I did a test build of my own, though, and once I figured out that it also requires users to edit their app preferences, it worked nicely.