I posted a question on askubuntu a while back. As there is no action, and I have also dug some more, I'll try here. Possibly a more correct place, (and I don't know if it is possible to move questions any more (I do not get any of those options)).
Anyhow:
Is there a way to get gnome-terminal profile ID? Need it in bash script – to do e.g. –
gconftool-2 "do some change to some value for current profile."
In my endeavour for an answer to this I have made some progress – but no satisfying solution. To be honest it truly scares me how shielded the application is from doing modifications from command line being a terminal emulator! To me it is incomprehensible.
Besides touching the source of gnome-terminal, (I do not wan a custom version), is there some legit way to get this? By the fact it is a wrapper for vte, it uses various shared libraries, some way I haven’t thought of, etc.
Add some C code into the mix is OK.
So far:
I have checked out the "save-config" option, but as it is 1. not satisfactory, aka 100%, and 2. more important this also is going to be removed it fails completely. See my own answer below for more detail.
There is no environment variable for this.
dbus: Doesn't seem to be any messages transmitted or any functions available for this kind of information. Have tested both current (3.6.0) version and latest develop.
injection: tho it is probable, and have played around with injecting custom code to it, it is such an error-prone endeavour it is not a solution.
If anyone wonder etc.
Decided to have another look at this - and made a little progress.
Using the built-in option --save-config there is these properties of interest:
Role=gnome-terminal-window-2587-1856448950-1359348087
ActiveTerminal=Terminal0xa896200
Geometry=110x87+900+1
WorkingDirectory=/home/xxx/tmp
Looking at it closer. Opened two windows in short succession and did a save-config.
Role
We can split it to the various parts:
gnome-terminal-window
2587
1856448950
1359348087
PID
2587 is same for both, and after a quick pstree 2587 -p we find it to be the PID. Further an echo $$ locates our bash (or which ever one prefer).
Time of start
Now the second number is wildly different giving a clue it is probably a random value. The last one, tho, is with only the last digit in diff. Most probably a time-stamp. I know I'm in tmp directory for this window - so, by using our knowledge of the proc file system:
# btime: boot time, in seconds since the Epoch
$ cat /proc/stat | grep ^btime | cut -d' ' -f2
1359039155
# starttime: The time in jiffies the process started after system boot.
$ cat /proc/$$/stat | cut -d' ' -f22
30893222
# WANT: 1359348087
btime + starttime / Hertz
1359039155 + (30893222 / 100) = 1359348087.22 ~ 1359348087
OK. Last digit is time-stamp on start by Epoch. But unfortunately it is not by jiffies and a rounded value so if we have started several windows by e.g. a script we can end up with same value.
(After some checking it also seems like seconds is rounded by round to nearest not towards zero etc.)
Random value
OK. So what about the value after PID? Most probably a random value, but to be sure. To check this we have to go to the source.
$ git clone git://git.gnome.org/gnome-terminal
$ gnome-terminal --version
GNOME Terminal 3.6.0
$ git log --grep="3\.6\.0"
commit f4d291a90dc4f513fc15f80fdebcdc3c3349b70a
...
Version 3.6.0
$ git checkout f4d291a90dc4f513fc15f80fdebcdc3c3349b70a
After some digging we find:
# terminal-util.c
48: void
terminal_util_set_unique_role (GtkWindow *window, const char *prefix)
{
char *role;
role = g_strdup_printf(
"%s-%d-%d-%d",
prefix,
getpid(),
g_random_int(),
(int) time (NULL)
);
gtk_window_set_role (window, role);
g_free (role);
}
OK. Not only do we confirm that the second is a random value, but also that PI and time is correct.
Geometry
xwininfo -id $(xdotool getactivewindow) | \
grep '^\s*-geometry' | \
sed 's/^\s*[^ ]* \(.*\)/\1/'
# yields 110x87+900+1
OK. Now we have three values to check against:
Time
Geometry
Path
Problem is that even with this we can easily have two windows with those values at same value. And more important; some genius has decided to remove this from the options of the application.
Terminal Window hex
Looking further at the code one find that the hex value in ActiveTerminal etc. is a pointer value to current address in memory of a struct holding current window. AKA not very usefull if one doesn't want to hack memory mappings.
Related
Long time listener (and a massive fan, this platform has me gotten out of predicaments more times that I can count), first time writer:
I am looking after a project where we run several Raspbian installs (Jesse Lite) that run chromium via an server in fullscreen - the whole boot process is automated - and the two tabs that get opened come from the /.config/chromium/default/preferences file;
In the relevant section, it says:
{"restore_on_startup":4,"startup_urls":["http://www.example.com/","https://www.example.org"]}
Since these units are essentially headless and I want to (Apple)Script my way to changing these URLs remotely, I looked into calling sed via ssh with public key on the raspberry pi 400s, and I have made good progress around the ssh and public key situation, but I am still not finding it easy to get my head around patterns and (double) escaping this query...
Purely on MacOS first, before getting into the ssh side of things, this is what I have come up with thus far:
sed -i .new 's/"startup_urls":[".*"]}/"startup_urls":["http://www.example.net","http://www.example.com"]}/g' ~/Library/Application\ Support/Google/Chrome/Default/Secure\ Preferences
However, that just gives me:
sed: 1: "s/"startup_urls":[".*"] ...": bad flag in substitute command: '/'
Any help and/or pointers greatly appreciated, otherwise - carry on!
Cheers,
Fred
It would seem there are a few issues here.
The default delimiter / is conflicting with characters in your input data, you would need to use an alternative delimiter
The start of the bracket is never matched [ as it needs to be escaped
You can try this sed to match and replace everything within the brackets
$ sed -i.bak s'|\[[^]]*|["http://www.example.net","http://www.example.com"|' ~/Library/Application\ Support/Google/Chrome/Default/Secure\ Preferences
{"restore_on_startup":4,"startup_urls":["http://www.example.net","http://www.example.com"]}
I'm was just trying out new things. I thought this would be a lot easier, but I can't find anything relative to what I am looking for, or what I find seems heavily outdated. A lot of results turn out fixes from years ago.
"lookThru ls -sl" seems to have been talked about, but that only produced Errors in regards to the used flags.
Other alternative involved having to have the name of the selected camera, but my attempt is to make this universal.
The lookThru command needs at least two arguments, first it wants to know the name of a modelingPanel to use and then the name of the camera. While it is easy to find out the name of the current camera with ls -sl getting the name of the modelingPanel is a bit more complicated, but there is a way to do it as you can see here: getting active panel
To look through the current camera use the following command:
select -r camera3;
lookThroughModelPanelClipped camera3 modelPanel4 0.01 100;
Or use lookThru command with near and far clipping planes:
lookThru -nc 0.01 -fc 100 perspView cameraShape3;
So after fiddling with this problem I was able to add this command to the marking menu using this.
$panel = `getPanel -wf`;
$cam = `ls -sl`;
lookThru $panel $cam;
For some silly reason lookThru won't accept ls -sl as an argument without a flag error so I could only get it to work by assigning ls -sl to cam.
For years I have being using variasons of du command below in order to produce a report of the largest files from specific location, and most of the time it worked well.
du -L -ch /var/log | sort -rh | head -n 10 &> log-size.txt
This this proved to get stuck in several cases, in a way that prevented stopping it with even the timeout -s KILL 5m ... approach.
Few years back this was caused by stalled NFS mounts but more recently I got into this in on VMs where I didn't use NFS at all. Apparently there is a ~1:30 chance to get this on openstack builds.
I read that following symbolic links (-L) can block "du" in some cases if there are loops but my tests failed to reproduce the problem, even when I created some loop.
I cannot avoid following the symlinks because that's how the files are organized.
What would be safer alternative to generate this report, one that would not block or at least if it does, it can be constrainted to a maximum running duration. It is essential to limit the execution of this command to a number of minutes -- if I can also get a partial result on timeouts or some debuggin info even better.
If you don't care about sparse files and can make do with apparent size (and not the on-disk size), then ls should work just fine: ls -L --sort=s|head -n10> log-size.txt
I have an Olimex Lime2 running an Armbian, headless. On this board I only care for SSH and MiniDLNA. I hope to get around to include the whole configuration, but one important bit might be that in /boot/armbianEnv.txt I put
extraargs=acpi=off
For one year now I experience very hard to debug issues with availability. The machine randomly stops to be accessible via ping or ssh. The issues are hard to debug because they seem to disappear when connecting monitor or keyboard while I can't find any trace of them when the system runs headless. While I got the problem mostly under control without knowing how, the Olimex still stops to respond now and then. This time I want to ask why.
I noticed that the Olimex stopped to provide DLNA access at 10/25th, ~2pm. I did not touch it to see if it recovers (which happens sometimes). This time the system remained unreachable for 2 days until I unplugged power.
Below you can find links to two logs. I would be very glad if anything suspicious in them could be pointed out so I can start resolving them.
One particular thing I wonder: Why did the system decided to reboot? There was no power outage at that day. I expect that a normal reboot would manifest itself in the logs, do they?
The logs:
/var/logs/messages: https://pastebin.com/qgRumreB
/var/logs/syslog: https://pastebin.com/U5jpHNHm
The logs are complete. I only removed lines in the beginning and at the end, but not in between.
Albeit I did not find a clear solution, I want to share what I have tried. Hopefully this will provide inspiration for others with similar problems.
One thing helping me a lot (which wasn't available back then) was to switch to a newer OS. I am running Armbian based on Ubuntu 18.04 and the logs are less cluttered now. Also, some minor details improved. If you landed here and still run Armbian Stretch, you should upgrade.
One reason for frequent crashes could be a corrupt file system, caused by frequent crashes :-(. Armbian mounts your SD card with
UUID=<uid> / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1
note the commit=600, which means that changes will be written only every 10 minutes. If your machine crashes inbetween, the file system might become corrupt. Thus, you might run fsck.ext4 on your SD card file system. In order to counteract the problem at all, you could:
run fsck at every boot
omit the commit setting. My SD card can handle the additional stress quite well.
What I think solved the problem for me is to put my external HDD, attached via SATA, to sleep. I was surprised that this does not happen automatically. Now I have the following section attached to my /etc/hdparm.conf:
/dev/disk/by-uuid/<uid> {
spindown_time = 60
write_cache = off
}
This tells hdparm to put the HDD to standby after 5 minutes of inactivity. Turning the write cache off is a safety measure against file system corruption again. Some disks reorder BtrFS write instructions when they shouldn't.
Something that I observed is that putting some load on the machine helped to keep the system alive. Unfortunately, that was true only until some point in time. However, if attaching Keyboard and Mouse or letting a script run throughout helps with restarts, you will have something to work with.
I use the following script to log information that might help me in case of a crash:
#!/bin/bash
# LICENSE: GPLv3 or later
set -euo pipefail
LOGFILE=/home/mgoerner/error-detection.log
function main() {
parse_cli_args "$#"
while true
do
print_debug_information >>"$LOGFILE" 2>&1
sync
sleep 3m
done
}
function parse_cli_args() {
if [[ $# -eq 1 ]]
then
arg="$1";shift
if [[ "$arg" == "--help" || "$arg" == "-h" ]]
then
print_usage
exit
fi
LOGFILE="$arg"
elif [[ $# -gt 1 ]]
then
echo "Please provide at most one argument!" >&2
exit 1
fi
}
function print_usage() {
cat <<EOF
$0 [LOGFILE]
EOF
}
function print_debug_information() {
echo
date
uptime
dmesg -uT | tail
ip addr show wlxd85d4c97e434
iwlist wlxd85d4c97e434 scan | egrep ESSID
hdparm -acdgkmurC /dev/sda
free
}
main "$#"
I let it start automatically after boot. Setting the sleep time under ~10 minutes used to let the crashes disappear, but does not anymore. Unfortunately, the error log produced by this script never helped getting any insight. The same goes for various logs from /var/log/. However, that might be different for you.
Furthermore, I suspect that my WiFi dongle does not like it warm. I reuse a childs shoe box as case and putting the dongle inside the closed box caused some connectivity problems.
Last but not least, I turned off automatic updates after reboots. Very often the crashes happened directly after some (mysterious) reboot. Having turned of automatic updates helped me getting rid of this altogether.
This is most similar to Get full path of executable of running process on HPUX…, except for AIX.
The basic question is: how, on AIX, can I determine the full path to the current executable? Having to do this before doing anything else (e.g., chdir) is fine.
The most accurate answer I've found so far is to check the output from
svmon -P $$ -O format=nolimit,filename=on,filtertype=client
(where $$ has its shell meaning: current pid). That's not only heavy amounts of C, but svmon is also not very fast and can easily overwhelm the runtime of the rest of the application.
The next best answer seems to be to simply look at argv[0], and, if it has a slash in it, it's either a full path name (starts with a leading /) or a relative-to-current-dir name (does not start with a leading /). If it doesn't have a slash in it, it's relative to something in PATH.
And if, after this resolution, I end up with a symlink, then there's all the resolution of symlink(s) to deal with as well (hard links are probably beyond the scope of any solution). This solution looks like it's relatively cross-platform, but is also very heavy in the C code (should be faster than svmon). And I expect there are race-conditions and such to deal with.
Thanks,
Update: I'm looking for a solution to submit to the perl devs. And they're going to worry about an insecure PATH, especially in setuid/setgid scenarios. See perlsec. I think that we could be okay here, but if you combined setuid with faking argv[0], you could force perl to think it's somewhere else, and load the wrong modules. The "next best" answer above only really works when not in perl's taint-mode.
Why can't you use ps options as a base line? Granted, you'll still need to process the cmd value to see if has a leading '/' or not. Something like
ps -o pid,env,cwd,cmd | grep youAppName | awk -f programToRationalizePathName
I don't have access to AIX anymore, but I did work on it for 2 1/2 years and I know I've used this sort of feature. I didn't think it was slow, but I might have had different requirements than you do.
I get the impression you want a utility function, a 1-at-time call that returns the full path, but if you need an on-going process and are concerned about re-starting ps every 1 minute (for example), look at the AIX specific nmon utility. Not sure if it can generate output similar to the ps -o cmd but it can be set up to run as long as you want, as often as you want (down to 1 second intervals) and it is just one process, whose output can be redirected as needed. (Nmon is not part of the std install, but most organizations do install it, as it is IBM blessed (if not supported directly)).
Of course all of the 'not 100%' caveats apply from the similar questions mentioned by you and in the comments.
I hope this helps.
Use ps to get executable path address
ps -aef | grep app | awk '{print $8}'
above command gives your app executable path address