Some apps don’t launch from antiX-CC gui

[Member seaken64]

Yesterday I pulled out my old Celeron M laptop to use it to browse the forums. I run antiX-17 as my main OS on this machine. I ran my usual updates and upgrades. I had a couple of instances where some apps on the Control Centre would not launch. This happened with the “Edit Config Files” off the System tab and “Partition a Drive” off the Disks tab.

I could open the config files directly with SpaceFM and I could launch Gparted from the command line with “sudo gparted”.

This failure to launch these apps happened several times. But I noticed that once they both worked after I had already launched and closed gparted from the command line or opened and closed the config files in Geany from SpaceFM. After this I tried a reboot to see if it was fixed. It still happened. But I noticed the hard drive light blinked when I clicked the app icon. I wondered if there was a file system glitch.

I booted to another partition and ran gparted and ran a clean/repair on the antiX-17 partition. I rebooted again into antiX-17. Now it is working.

I am wondering if my diagnosis makes sense. Why would the antiX-CC fail to launch a program? Could it be a failing disk drive?

I was wondering if I could reinstall the antiX-CC but I couldn’t find the package to use to do that. I’m still pretty sketchy on understanding how these antiX programs all fit together.

Anyway, it’s working now. Maybe my disk clean/repair did the trick. I have noticed this phenomenon before. But I can’t put my finger on where and when. I think it was on my “testing” version of antiX-19 32-bit. But this was on antiX-17. The antiX-19 partition on this laptop is not having any problems with the antiX-CC.

seaken64

[Member seaken64]

Helpful

Up

0

::

I rebooted again and the problem persists. I click the icon for “Edit Config Files” or “Partition a Drive” and they do not launch. I see the hard drive light blink but then nothing, it stalls.

I noticed a line when booting saying the hardware clock may not be set correctly. I went into BIOS setup and made sure the time was set. It was set to the correct time. Rebooted.

I tried to open Synaptic software manager from the menu but it did not launch. Weird. I launched it from the command line with “sudo synaptic”. I searched for “Control Centre” and found the package for the antiX-CC and marked it for reinstall then applied to reinstall the package. After it finished I tried the CC again. Now it is working again.

I’m not sure if my troubleshooting is going in the right direction. Why does the command line work to launch these programs but they sometimes fail from the CC or IceWM menu? I obviously am not understanding something about launching these programs from the GUI. And the fact that it seems to be sporadic makes it hard to diagnose.

Anyway, maybe my hard drive is going bad. Strangely, everything works on antiX-19 on another partition on same drive. Maybe I’ll never know. Anomalies can be difficult to comprehend.

seaken64

[Member seaken64]

Helpful

Up

0

::

Here’s the machine quick info:

$ inxi -Fxzr
System:
  Host: antix17 Kernel: 4.10.5-antix.1-486-smp i686 bits: 32 compiler: gcc v: 6.3.0 
  Desktop: IceWM 1.4.2 Distro: antiX-17_386-full Heather Heyer 24 October 2017 
  base: Debian GNU/Linux 9 (stretch) 
Machine:
  Type: Portable System: Gateway product: MX3210 v: 73.03 serial: <filter> 
  Mobo: Gateway model: N/A v: Rev1.73.03 serial: <filter> BIOS: Phoenix v: 73.03 
  date: 01/06/2006 
Battery:
  ID-1: BAT0 charge: 20.9 Wh condition: 21.1/48.8 Wh (43%) model: Gateway W32044L 
  status: Unknown 
CPU:
  Topology: Single Core model: Intel Celeron M bits: 32 type: MCP arch: M Dothan 
  rev: 8 L2 cache: 1024 KiB 
  flags: pae sse sse2 bogomips: 2793 
  Speed: 1397 MHz min/max: N/A Core speed (MHz): 1: 1397 
Graphics:
  Device-1: VIA CN700/P4M800 Pro/P4M800 CE/VN800 Graphics [S3 UniChrome Pro] 
  vendor: Gateway driver: N/A bus ID: 01:00.0 
  Display: server: X.Org 1.19.2 driver: openchrome unloaded: fbdev,modesetting,vesa 
  resolution: 1280x768~60Hz 
  OpenGL: renderer: Gallium 0.4 on llvmpipe (LLVM 3.9 128 bits) v: 3.3 Mesa 13.0.6 
  direct render: Yes 
Audio:
  Device-1: VIA VT8233/A/8235/8237 AC97 Audio vendor: Gateway driver: snd_via82xx 
  v: kernel bus ID: 00:11.5 
  Sound Server: ALSA v: k4.10.5-antix.1-486-smp 
Network:
  Device-1: Broadcom Limited BCM4318 [AirForce One 54g] 802.11g Wireless LAN 
  driver: b43-pci-bridge v: N/A bus ID: 00:0e.0 
  Device-2: VIA VT6102/VT6103 [Rhine-II] vendor: Gateway driver: via-rhine v: N/A 
  port: 1800 bus ID: 00:12.0 
  IF: eth0 state: down mac: <filter> 
  IF-ID-1: wlan0 state: up mac: <filter> 

[Member seaken64]

Helpful

Up

0

::

I wonder if this is related but I noticed a couple of times that the command line prompts does not come back after a completion of a routine. I just noticed after running inxi. Usually the command prompt comes back.

I also noticed it after the apt full-upgrade and the Synaptic re-install of Control Centre.

Something appears to be going on. What would cause this behavior?

seaken64

[Member seaken64]

Helpful

Up

0

::

Ahh, a clue! The inxi paused after the Network but before the Drives section. There is something going on with the hard drive. It did eventually catch up and the prompt came back. Hmm.

inxi continued….

Network:
  Device-1: Broadcom Limited BCM4318 [AirForce One 54g] 802.11g Wireless LAN 
  driver: b43-pci-bridge v: N/A bus ID: 00:0e.0 
  Device-2: VIA VT6102/VT6103 [Rhine-II] vendor: Gateway driver: via-rhine v: N/A 
  port: 1800 bus ID: 00:12.0 
  IF: eth0 state: down mac: <filter> 
  IF-ID-1: wlan0 state: up mac: <filter> 
Drives:
  Local Storage: total: 37.26 GiB used: 4.06 GiB (10.9%) 
  ID-1: /dev/sda vendor: Hitachi model: HTS424040M9AT00 size: 37.26 GiB 
Partition:
  ID-1: / size: 7.72 GiB used: 4.06 GiB (52.6%) fs: ext4 dev: /dev/sda6 
Sensors:
  System Temperatures: cpu: 50.0 C mobo: N/A 
  Fan Speeds (RPM): N/A 
Repos:
  Active apt repos in: /etc/apt/sources.list.d/antix.list 
  1: deb http://repo.antixlinux.com/stretch/ stretch main nosystemd nonfree
  Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list 
  1: deb http://ftp.us.debian.org/debian/ stretch-updates main contrib non-free
  Active apt repos in: /etc/apt/sources.list.d/debian.list 
  1: deb http://ftp.us.debian.org/debian/ stretch main contrib non-free
  2: deb http://security.debian.org/ stretch/updates main contrib non-free
  Active apt repos in: /etc/apt/sources.list.d/home:smplayerdev.list 
  1: deb http://download.opensuse.org/repositories/home:/smplayerdev/Debian_9.0/ /
  No active apt repos in: /etc/apt/sources.list.d/onion.list 
  No active apt repos in: /etc/apt/sources.list.d/various.list 
Info:
  Processes: 142 Uptime: 37m Memory: 478.9 MiB used: 283.1 MiB (59.1%) Init: SysVinit 
  runlevel: 5 Compilers: gcc: 6.3.0 Shell: bash v: 4.4.12 inxi: 3.0.36 

[Anonymous]

Helpful

Up

0

::

gparted
[..]
synaptic
[..]
Why would the antiX-CC fail to launch a program?

Perhaps introduced via changes (updated packages) implemented by debian after the days of betatesting antiX 17, we are now faced with the following:

https://sources.debian.org/src/gparted/0.25.0-1/debian/patches/02_use-pkexec.patch/

https://sources.debian.org/src/synaptic/0.84.2/data/synaptic.desktop.in/

debian patches gparted to require pkexec (polkit)
and
same for synaptic (per the Exec= line in the synaptic .desktop file)

On my antiX17, a polkit authentication agent (daemon) is not running.
(I don’t recall whether that agent was autostarted, by default, in the stock antiX17.)
If a similar scenario exist on your machine (no polkit agent running), yes, those launchers would fail.
The desktop menu content is built by parsing the instalaled *.desktop files.
If a .destop specifies Exec=blahbla, that launchstring winds up included in the menu… and fails.

^— explaining “why some things may launch successfully via commandline, or via ControlCentre, but their ‘same-named’ menu entries fail to launch”

ControlCentre, aka /usr/local/bin/antixcc.sh, the launchstrings therein are handcrafted.
You can, if curious to learn, view /usr/local/bin/antixcc.sh in a text editor to learn what launchstring is associated with each of the cc “iconic buttons”,
Also, you might use a terminal emulator to run “antixcc.sh” and watch for any details reported to commandline if/when a particular cc button fails to launch.

Why would the antiX-CC fail to launch a program?
[..]
I click the icon for “Edit Config Files”

Well, the associated launchstring is this:
gksu $EDITOR /etc/fstab /etc/default/keyboard /etc/grub.d/* /etc/slim.conf /etc/apt/sources.list.d/*.list
so, enter that same launchstring at a command prompt and watch for whatever error message(s) are displayed.

[Member seaken64]

Helpful

Up

0

::

@skidoo, thanks for those tips. That makes sense to me – that a Debian update has broken the default launch string as originally hard coded into antiX-17 or that a new process, like pkexec, is now used to launch some of these programs.

I will read up on this and see if I can fix the launch strings for my antiX-17 machines.

I tested the hard drive and partitions with GSmartControl and Gparted. Everything checked out. So it makes more sense now that it’s a script problem rather than a drive failure.

Thanks again for pointing me in the right direction.

seaken64

[Member seaken64]

Helpful

Up

0

::

I’ve done a lot of reading today on gksu, sudo, pkexec. I’m still largely confused. But it seems that my antiX-17 does not have the setup for gparted and synaptic. As I understand it these programs have been updated in Debian to utilize the pkexec ,or polkit, security system and antiX is set to use gksu. I’m not clear on this at all and I may not understand this like I think I do.

As an experiment I opened /usr/local/bin/antixcc.sh and changed the action command for gparted from “gksu gparted &” to “sudo gparted &” and saved and restarted the session. When I tried to launch gparted from the Control Centre it worked. But I am still not sure if this is the right solution. Should I be trying to setup polkit instead?

I used the sudo command because I use it all the time at the command line to open spacefm with root privileges and I was successful using it with gparted from the command line. It seemed a logical choice for me. But I am reading so many things that claim I shouldn’t do this or that. It’s confusing.

My roots at the command line are from CP/M and DOS and I have learned to be careful and I know when I am in danger and I make backups before editing, etc. How unsafe can it be for me to launch a GUI app from the Control Centre with sudo? I don’t understand what the difference is using gksu or sudo or pkexec. To me the end result is the same. My chosen program launches with me in control.

Now, I assume my edits to antixcc.sh will be overwritten if it gets upgraded. So I am sure there is a better way. But I’m stumbling in the dark for now. I’ll keep reading. Maybe I’ll get it eventually.

seaken64

[Member seaken64]

Helpful

Up

0

::

Ahh, still confused. I thought maybe it made a difference to use “sudo” in the launch string. But I checked the launch string on the IceWM menu as found in the /usr/share/applications/antix/gparted.desktop and it uses “gksu” and it worked. When I click on the menu item “gparted” I get a password box and then it launches gparted. This is normal behavior, but using gksu, not sudo, or pkexec. So I’m not sure if my edit on the Control Centre makes a difference. It’s still a mystery to me why it did not launch from the Control Centre until after I edited it.

seaken64

P.S. – I just checked Synaptic and Edit Config Files on the Control Centre. They both launched fine, with no password prompt. Strange that they would not launch yesterday. Maybe editing and saving the antixcc.sh script made a difference. I have no idea.

• This reply was modified 2 years ago by seaken64.

[Anonymous]

Helpful

Up

0

::

They both launched fine, with no password prompt. Strange that they would not launch yesterday.

man sudoers
while viewing the manpage, press / (forward slash) to initiate a search
search for: timeout
and read to understand that “succeeded today because” is likely due to a timeout grace period initiated by having already used sudo for some other command wihtin the past 15 minutes.

at the commandline, type:
sudo visudo
and skimread the contents of the sudo policy file. Refer to the manpage (man sudo) to learn about unfamiliar items. In case you don’t catch this detail, I’ll mention that sudo consults /etc/sudoers.d/* and loads rules found in any files pathed therein… and, on antiX, a rules file (/etc/sudoers.d/antixers) is pre-installed. Skimreading the antixers file will give a fuller picture of the rules that are in play.

gksu
In a nutshell, it acts like an alias (disclaimer: this is an oversimplification), invoking
sudo -H -S -p SUDO_PASS -u root –– <somecommandstring>
and displays a popup dialogbox to input your password

polkit (formerly referred to as “policykit”)
It fills the role of sudo, and usually (in most implementations, across most distros) runs as a daemon…

$ apropos polkit
$ apropos policykit
$ apropos pkexec
  ^---v
pklocalauthority (8) - PolicyKit Local Authority
polkit (8)           - Authorization Framework
polkitd (8)          - PolicyKit daemon
pkexec (1)           - Execute a command as another user

man polkit
^–> to read about its mechanations, and its use of a separate dialogbox-popping “authentication agent”

polkit rules reside here: /usr/share/polkit-1/actions/*
and, different from sudo, an ‘app’ can be launched with normal permissions… and no auth is requested until/unless an event (buttonclick, etc.) associated with protected functionality is attempted. Auth is granted for the process associated with that event rather than for the overall app instance. If no daemon, no “authorization agent” helper is running though… the auth request will just silently fail.

Example:
/usr/share/polkit-1/actions/com.ubuntu.pkexec.synaptic.policy
^–> The app can be launched with normal permissions, in “lookaround” mode. At time of requesting add/remove, an auth prompt is presented. User will enter a password, but maybe the sysadmin has set rules restricting this particular user from performing the requested action, so will be denied. Again, if no daemon, no “authorization agent” helper is running, the auth request would just silently fail.

The “modern thinking marketing” salespitch is that polkit+pkexec provides a more flexible, more granular mechanism. Great for corporations, corporate sysadmins… sucky for desktop self-sysadmins. No “gui” exists to facilitate rule (policyaction) creation, the namespace is bassackwards and rules files demand use of arcane XML-ish syntax.

[Member seaken64]

Helpful

Up

0

::

Thank you skidoo. You’ve been very patient, and informative! I’ve read a lot of your writing on this subject. But I missed the connection to the “timer” from having invoked sudo previously. Now it makes sense. I will continue reading as you suggest and I will try again tomorrow to see if I can still launch some of these programs when there is no timer in effect. That was a great tip! Thanks.

seaken64

[Author]

Posts