Author Topic: Sparky APTus failes to launch {Solved}  (Read 2658 times)

Offline GeneC

  • Full Member
  • ***
  • Posts: 129
Sparky APTus failes to launch {Solved}
« on: September 01, 2014, 05:46:30 pm »

Its working OK, now, possibly just need re-boot
Sparky APTus got removed when removing some other software.  I re-installed it,
Code: [Select]
Commit Log for Mon Sep  1 11:38:58 2014

Installed the following packages:
dctrl-tools (2.23)
sparky-aptus (0.2.2)
sparky-aptus-extra (0.1.2)
ssft (0.9.13)
vrms (1.16)
yad (0.27.0-1)
zenity (3.12.1-1.1)
zenity-common (3.12.1-1.1)
but it will not launch.

Code: [Select]
gene@sparky:~$ remsu /usr/bin/sparky-aptus
glibtop: Non-standard uts for running kernel:
release 3.15-6.dmz.2-liquorix-amd64=3.15.0 gives version code 200448

yad: cannot create shared memory for key 123450: File exists
« Last Edit: September 01, 2014, 11:15:18 pm by GeneC »

Offline pavroo

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2027
    • SparkyLinux
Re: Sparky APTus failes to launch {Solved}
« Reply #1 on: September 01, 2014, 11:49:56 pm »
That's right.
Tabbed yad uses shared memory key.
If yad's start up failed it can't use the same key again, so the best way is rebooting.
Nothing is easy as it looks. Danielle Steel
Join #sparkylinux at

Offline MoroS

  • Sr. Member
  • ****
  • Posts: 258
  • Problem solver ;)
Re: Sparky APTus failes to launch {Solved}
« Reply #2 on: September 04, 2014, 02:03:59 pm »
That's quite specific to shared memory usage. The shared memory is managed by the kernel and the only means of getting a shared memory area for your processes if by asking the kernel by giving him your ID (the key in this case). The processes that should have access to that shared area should always use the same key and they should clean up afterwards. The issue here can be one of the following:
1. Yad didn't clean up the shared memory area when previoulsy running (a fatal process termination like a segmentation fault could be the reason).
2. Yad doesn't use the shared memory already reserved for the given key (no wonder, it's risky, as another process can use the same key, so it's a common practice is to base the key on something more unique like process' ID).
Whatever the case, a reboot resolves the situation, as it reinitializes the kernel and the memory area is no more.
There isn't a single thing that's impossible. Just the things that we don't yet know how to deal with. ;)