how can i stop PackageKit -

English Applications
#1

how can i stop PackageKit

i want to run sudo zypper up

since i run in a bug
https://forums.opensuse.org/showthread.php/507325-opensue-stops-to-refresh-the-system-349-packages-still-left-in-the-queue-so-what

note. i had luck in running the abofe mentioned command - but now (today) i try to do so on a new notebook - now i have to install ++ updates… in opensuse.#
note: the notebook was not in use for more than 1 month.

but packagekit does not want me to do so - does not allow this…

it allways stops the process

PackageKit blockiert zypper. Dies passiert, wenn Sie ein Aktualisierungsmodul oder eine andere Softwareverwaltungsanwendung benutzen, die PackageKit verwendet.
PackageKit beenden? [ja/nein] (nein): j
PackageKit läuft noch (wahrscheinlich aktiv).
Erneut versuchen? [ja/nein] (nein): j
PackageKit läuft noch (wahrscheinlich aktiv).

need your help now

look forward to hear from you

#2

kill packagekit from command line

ps -A
lists all processes
find the PID (process ID) of packagekit

then
kill PID
where PID is the ID for packagekit

I forgot if you have to be root. Probably would not hurt

With package kit dead and as root

zypper up

#3

Or “sudo killall packagekitd” would also work.

Or use KDE’s system monitor (Ctrl+ESC), it will ask you for the root password if you try to kill a root process (or any process running as another user).

I forgot if you have to be root. Probably would not hurt

Yes. packagekitd runs as root.

That said, if packagekitd is always blocking, something seems to be wrong with your repos.
It should shut itself down after 15 seconds of inactivity.

So check too that you don’t have any repos that are not reachable at the moment. E.g. try to run “sudo zypper ref” after you killed packagekitd.

#4

hello

many thanks - this is very helpful

guess that the pid is 2037

should i run kill PID2037

see the following

Die Systemverwaltung ist durch die Anwendung mit dem PID 2037 (/usr/lib/packagekitd) gesperrt.
Schließen Sie diese Anwendung, bevor Sie es erneut probieren.
martin@linux-o61y:~> ps -A
  PID TTY          TIME CMD
    1 ?        00:00:04 systemd
    2 ?        00:00:00 kthreadd
    3 ?        00:00:01 ksoftirqd/0
    5 ?        00:00:00 kworker/0:0H
    7 ?        00:00:01 rcuc/0
    8 ?        00:00:00 rcub/0
    9 ?        00:00:04 rcu_preempt
   10 ?        00:00:00 rcu_sched
   11 ?        00:00:00 rcu_bh
   12 ?        00:00:00 migration/0
   13 ?        00:00:00 watchdog/0
   14 ?        00:00:00 watchdog/1
   15 ?        00:00:00 migration/1
   16 ?        00:00:00 rcuc/1
   17 ?        00:00:00 ksoftirqd/1
   19 ?        00:00:00 kworker/1:0H
   20 ?        00:00:00 watchdog/2
   21 ?        00:00:00 migration/2
   22 ?        00:00:00 rcuc/2
   23 ?        00:00:00 ksoftirqd/2
   25 ?        00:00:00 kworker/2:0H                                                                                                                                                            
   26 ?        00:00:00 watchdog/3                                                                                                                                                              
   27 ?        00:00:00 migration/3                                                                                                                                                             
   28 ?        00:00:00 rcuc/3                                                                                                                                                                  
   29 ?        00:00:00 ksoftirqd/3                                                                                                                                                             
   31 ?        00:00:00 kworker/3:0H                                                                                                                                                            
   32 ?        00:00:00 khelper                                                                                                                                                                 
   33 ?        00:00:00 kdevtmpfs
   34 ?        00:00:00 netns
   35 ?        00:00:00 khungtaskd
   36 ?        00:00:00 writeback
   37 ?        00:00:00 ksmd
   38 ?        00:00:01 khugepaged
   39 ?        00:00:00 crypto
   40 ?        00:00:00 kintegrityd
   41 ?        00:00:00 bioset
   42 ?        00:00:00 kblockd
   44 ?        00:00:00 ata_sff
   45 ?        00:00:00 khubd
   48 ?        00:00:00 kswapd0
   49 ?        00:00:00 fsnotify_mark
   56 ?        00:00:00 kthrotld
   58 ?        00:00:00 scsi_eh_0
   59 ?        00:00:00 scsi_tmf_0
   60 ?        00:00:00 scsi_eh_1
   61 ?        00:00:00 scsi_tmf_1
   64 ?        00:00:00 kpsmoused
   66 ?        00:00:00 ipv6_addrconf
   67 ?        00:00:00 deferwq
   70 ?        00:00:00 kworker/2:1H
  110 ?        00:00:00 kauditd
  122 ?        00:00:00 kworker/1:2
  131 ?        00:00:00 kworker/0:2
  205 ?        00:00:00 kworker/3:2
  223 ?        00:00:00 kworker/0:1H
  227 ?        00:00:00 kworker/3:1H
  234 ?        00:00:00 kworker/1:1H
  251 ?        00:00:00 jbd2/sda6-8
  252 ?        00:00:00 ext4-rsv-conver
  337 ?        00:00:01 systemd-journal
  345 ?        00:00:00 dmeventd
  346 ?        00:00:00 lvmetad
  362 ?        00:00:00 systemd-udevd
  373 ?        00:00:02 haveged
  397 ?        00:00:00 acpi_thermal_pm
  400 ?        00:00:00 cfg80211
  401 ?        00:00:00 irq/106-mei_txe
  413 ?        00:00:00 hd-audio0
  425 ?        00:00:00 kmemstick
  455 ?        00:00:00 jbd2/sda7-8
  456 ?        00:00:00 ext4-rsv-conver
  473 ?        00:00:00 auditd
  641 ?        00:00:00 avahi-daemon
  644 ?        00:00:00 wpa_supplicant
  646 ?        00:00:00 ModemManager
  649 ?        00:00:04 dbus-daemon
  650 ?        00:00:06 nscd
  656 tty1     00:00:00 agetty
  721 ?        00:00:00 systemd-logind
  726 ?        00:00:02 NetworkManager
  728 ?        00:00:00 polkitd
  743 ?        00:00:00 kdm
  759 ?        00:00:00 cupsd
  808 tty7     00:03:46 Xorg
  984 ?        00:00:00 kdm
 1050 ?        00:00:00 master
 1051 ?        00:00:00 pickup
 1052 ?        00:00:00 qmgr
 1067 ?        00:00:00 cron
 1092 ?        00:00:00 systemd
 1093 ?        00:00:00 (sd-pam)
 1094 ?        00:00:00 startkde
 1176 ?        00:00:00 dbus-launch
 1177 ?        00:00:00 dbus-daemon
 1178 ?        00:00:00 gpg-agent
 1218 ?        00:00:00 start_kdeinit
 1219 ?        00:00:00 kdeinit4
 1220 ?        00:00:00 klauncher
 1222 ?        00:00:08 kded4
 1225 ?        00:00:01 kglobalaccel
 1234 ?        00:00:00 kactivitymanage
 1235 ?        00:00:00 upowerd
 1250 ?        00:00:01 udisksd
 1255 ?        00:00:00 kwrapper4
 1257 ?        00:00:01 ksmserver
 1267 ?        00:01:35 kwin
 1275 ?        00:03:53 plasma-desktop
 1276 ?        00:00:01 baloo_file
 1284 ?        00:00:00 bluetoothd
 1295 ?        00:00:00 kuiserver
 1306 ?        00:00:02 krunner
 1309 ?        00:00:01 kmix
 1316 ?        00:00:08 konsole
 1318 ?        00:00:42 pulseaudio
 1319 ?        00:00:00 rtkit-daemon
 1320 ?        00:00:22 kwrite
 1335 ?        00:00:00 polkit-kde-auth
 1336 ?        00:00:00 klipper
 1340 pts/0    00:00:00 bash
 1385 ?        00:00:01 filezilla
 1386 ?        00:31:18 firefox
 1390 ?        00:00:00 knotify4
 1404 ?        00:00:00 gvfsd
 1416 ?        00:00:00 gvfsd-fuse
 1500 ?        00:00:00 at-spi-bus-laun
 1505 ?        00:00:01 kmozillahelper
 1577 ?        00:00:00 dhclient
 1695 ?        00:00:02 ksysguardd
 2011 ?        00:00:00 kworker/2:0
 2037 ?        00:00:11 packagekitd
 2680 ?        00:00:00 kworker/3:1
 2684 ?        00:00:00 kworker/2:1
 2749 ?        00:00:00 kworker/0:1
 2803 ?        00:00:01 kworker/u8:0
 2839 ?        00:00:00 kworker/u8:2
 2841 ?        00:00:00 kworker/1:0
 2892 ?        00:00:00 kworker/1:1
 2897 ?        00:00:00 kworker/2:2
 2901 ?        00:00:00 kworker/u8:1
 2912 pts/0    00:00:00 ps
martin@linux-o61y:~> kill PID 2037 
bash: kill: PID: Die Argumente müssen Prozess- oder Jobbezeichnungen sein.
bash: kill: (2037) - Die Operation ist nicht erlaubt
martin@linux-o61y:~> PID 2037 
If 'PID' is not a typo you can use command-not-found to lookup the package that contains it, like this:
    cnf PID
martin@linux-o61y:~> kill PID 2037
#5

Yes, as even zypper tells you already.

But, see my previous reply.

#6

DO NOT use the letters PID that is not part of the command only indicates you need to put the PID number there not the letters PID.

#7

On Tue 30 Jun 2015 08:06:02 PM CDT, dilbertone wrote:

hello

many thanks - this is very helpful

guess that the pid is 2037

should i run kill PID2037

see the following

2037 ? 00:00:11 packagekitd

Hi
You also need to add the signal (hint kill -l <–that’s a lower case
L)… and if you know the name, then can use pidof…


kill -9 `pidof packagekitd`

or

kill -9 2037

–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel
3.12.43-52.6-default If you find this post helpful and are logged into
the web interface, please show your appreciation and click on the star
below… Thanks!

#8

Rather than go through complicated steps to find the PID of the process you want to end, you can just use pkill, followed by the name of the process you want to end, so in this case

pkill packagekit

should work.

#9

The process is called “packagekitd”, so it should be:

pkill packagekitd

(run as root)

Or “killall packagekitd” would work as well, as I mentioned already.

Still, it should not be necessary at all. Packagekitd should quit itself after 15 seconds of inactivity.
If it doesn’t something else is wrong.

#10

I have had packagekit be reluctant to stop several times on the last several updates. It seems to hang. Only why is to kill it. Logging out and back in just restarts the program. This last time it did actually do the update on logging back in but in the recent past I had to kill it.

#11

You probably see https://bugzilla.opensuse.org/show_bug.cgi?id=908730
Well, that’s a bug.
But it only happens when you actively use it to install a flash-player update (or any other that requires a license agreement).

Only why is to kill it.

Running “pkcon get-updates” e.g. or open Apper and click on “Updates” should “wake it up” and make it continue.

#12

On 2015-07-02 17:46, gogalthorp wrote:
>
> I have had packagekit be reluctant to stop several times on the last
> several updates. It seems to hang. Only why is to kill it. Logging out
> and back in just restarts the program. This last time it did actually
> do the update on logging back in but in the recent past I had to kill
> it.

I remove it on most of my installs, for different reasons, and that’s
one of them. But for instance, on this laptop, I remove it because I do
not want something doing downloads (even if only metadata) when I’m
connected via limited or metered Internet. For instance, via cell phone,
or via wifi spot. Or even via a slow adsl.

But then, I object to it running for every user that logs in. Only the
user(s) that does the maintenance should see the applet and be
authorized to run it. I don’t know of a way to control this.

I guess all of that reduces to “having full control” of who and when :slight_smile:

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

#13

This should be possible via a custom javascript snippet in /etc/polkit-1/rules.d/, i.e. one that only returns “ok” for one specific user or group.
See also “man 8 polkit”.

Something like this should work:

/* Allow only user myadmin to install updates with PackageKit */
polkit.addRule(function(action, subject) {
    if ( action.id == "org.freedesktop.packagekit.system-update" )
    {
        if (subject.user == "myadmin" /* change this to subject.isInGroup("wheel") to apply to all users in the "wheel" group */ )
        {
            return polkit.Result.YES;
        }
        else
        {
            return polkit.Result.NO;
        }
    }
});

The default rules/actions only differentiate between users logged in locally (in an “active” session in polkit speak), users logged in locally in an “inactive” session, and others.

#14

Does this remove the Applet from the user’s desktop? When not, (s)he has now a useless Applet, which may be more secure, but not very user friendly.

Simply not installing Apper (nor Packagekit) seems a “cleaner” solution to me.

#15

Of course it doesn’t remove the applet.
You’d have to do that manually (or change the defaults to not add the applet for a new user account), or you could modify the applet to not display itself for other users…

But the snippet does not only apply to the applet, but all PackageKit frontends.
And you could change the line “return polkit.Result.NO” to “return polkit.Result.AUTH_ADMIN_KEEP”, which would allow all other users to use it too, but they would have to enter the root password to do so.

Simply not installing Apper (nor Packagekit) seems a “cleaner” solution to me.

Yes, but then no user can install updates without a root password, unless you modify the sudo config e.g.

#16

On 2015-07-02 21:26, wolfi323 wrote:
>
> hcvv;2717828 Wrote:
>> Does this remove the Applet from the user’s desktop? When not, (s)he
>> has now a useless Applet, which may be more secure, but not very user
>> friendly.
> Of course it doesn’t remove the applet.
> You’d have to do that manually (or change the defaults to not add the
> applet for a new user account), or you could modify the applet to not
> display itself for other users…

I’d rather try change the executable bit of the applet, so that only
people in a certain group can run it.

> But the snippet does not only apply to the applet, but all PackageKit
> frontends.

True.

> And you could change the line “return polkit.Result.NO” to “return
> polkit.Result.AUTH_ADMIN_KEEP”, which would allow all other users to use
> it too, but they would have to enter the root password to do
> so.

Mmm.

>> Simply not installing Apper (nor Packagekit) seems a “cleaner” solution
>> to me.
> Yes, but then no user can install updates without a root password,
> unless you modify the sudo config e.g.

Which is basically what I want… only the admin doing admin work :slight_smile:

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

#17

Exactly. Simple action (do not intall or remove Packagekit), with the desired results.

#18

You don’t “run” an applet, in particular not KDE’s updater applet.
It’s written in QML (some kind of JavaScript) and is loaded by the system tray.

Modifying the “executable bit of the applet” doesn’t help at all here.

You could probably change the readable bit, but then all other users would get some error message I suppose.
I would rather prevent the applet from being added to the system tray at all. This is done by a plasma script on first login.
Plasma remembers which setup scripts it runs in ~/.kde4/share/config/plasma-desktoprc, so just create one (via /etc/skel/ e.g.) with the following content:

[Updates]

performed=/usr/share/kde4/apps/plasma-desktop/updates/10-opensuse-org.packagekit.updater.js

And new user accounts won’t have an update applet in KDE. This won’t prevent users from adding it themselves though, or running e.g. Apper, so you should still change the polkit rules accordingly.

Your method should work with stand-alone applications like Apper, gnome-software, or pk-update-viewer though.

Which is basically what I want… only the admin doing admin work :slight_smile:

In this case, no special polkit rule is needed.
Just set the security level to “restrictive”, or set this in /etc/polkit-default-privs.local:

org.freedesktop.packagekit.system-update auth_admin_keep

Then everybody has to enter the root password, except root itself of course.

Or uninstall PackageKit and all its frontends.

Then just do it that way.

#19

On 2015-07-03 10:16, wolfi323 wrote:
>
> robin_listas;2717858 Wrote:

>> I’d rather try change the executable bit of the applet, so that only
>> people in a certain group can run it.

> You don’t “run” an applet, in particular not KDE’s updater applet.
> It’s written in QML (some kind of JavaScript) and is loaded by the
> system tray.
>
> Modifying the “executable bit of the applet” doesn’t help at all here.

Oh.

> You could probably change the readable bit, but then all other users
> would get some error message I suppose.

Not too bad… :slight_smile:

> I would rather prevent the applet from being added to the system tray at
> all. This is done by a plasma script on first login.

But they could add it manually later, no?

> Plasma remembers which setup scripts it runs in
> ~/.kde4/share/config/plasma-desktoprc, so just create one (via
> /etc/skel/ e.g.) with the following content:
>
> Code:
> --------------------
> [Updates]
>
> performed=/usr/share/kde4/apps/plasma-desktop/updates/10-opensuse-org.packagekit.updater.js
>
>
> --------------------
>
> And new user accounts won’t have an update applet in KDE. This won’t
> prevent users from adding it themselves though, or running e.g. Apper,
> so you should still change the polkit rules accordingly.

Ah.

> Your method should work with stand-alone applications like Apper,
> gnome-software, or pk-update-viewer though.

Well, you see, changing permissions is doable in /etc/permissions.local
and is thus enforced for life.

>> Which is basically what I want… only the admin doing admin work :slight_smile:
>
> In this case, no special polkit rule is needed.
> Just set the security level to “restrictive”, or set this in
> /etc/polkit-default-privs.local:
>
> Code:
> --------------------
> org.freedesktop.packagekit.system-update auth_admin_keep
> --------------------
>
> Then everybody has to enter the root password, except root itself of
> course.

I seem to recall this.

> Or uninstall PackageKit and all its frontends.

Well, that’s what I actually do :slight_smile:

I’m just thinking of other, less drastic, alternative measures :slight_smile:
Thanks for your ideas :slight_smile:

I will save this post. Unfortunately, I will forget I did :frowning:

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))