Has consolekit not been replaced yet?

weirddan455 · 2012-10-30 23:04:33

Saw the news item so I did a full update. I still can't remove consolekit because of dependecies though. Has the update just not been pushed out yet or am I required to do something?

sudo pacman -R consolekit
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: slim: requires consolekit
:: xfce4-session: requires consolekit

Scimmia · 2012-10-30 23:05:17

It just got pushed from testing in the last few minutes. Wait for the mirrors to update.

Last edited by Scimmia (2012-10-30 23:05:56)

WonderWoofy · 2012-10-30 23:06:48

I think the news was just pushed to make users aware that the changes are about to come. As I ahve not seen the repos updated to fully reflect the change yet. In fact, I beloeve the necessary polkit is still only available in testing. You ned to have polkit 0.107-4 for it to be compatible with logind

Scimmia · 2012-10-30 23:10:30

Check it again, WonderWoofy, they're being pushed to the main repos as we speak.

weirddan455 · 2012-10-31 01:20:25

Alright I got the update now and removed console kit without any dependency problems. I wasn't trying to be impatient. I just didn't know what time the news item was posted.

WonderWoofy · 2012-10-31 01:40:35

Yes, I apparently posted mere minutes before it was actually pushed. In any case I ahve been using thesting repos for a bit over a week, and all is well.

kinleyd · 2012-10-31 03:33:49

Does pacman -Rs consolekit also remove the consolekit systemd services or do we have to do that manually?

Edit: It doesn't seem to be fully removed. The following two are no longer listed with systemctl --all:

console-kit-daemon.service
console-kit-log-system-start.service

But consolekit.service still appears with "error | inactive | dead" against it.

What is the command to remove this (and other) dead services?

systemctl disable consolekit.service only gives this error: "Failed to issue method call: No such file or directory".

Thanks.

Last edited by kinleyd (2012-10-31 03:56:44)

WonderWoofy · 2012-10-31 04:07:47

Since you didn't disable them before removal (which I don't even know if it was possible or not), you probably have to go and delte the symlinks themselves.

I must say, good riddence to consolekit! I definitely agree with the sentiments posted on one of the mailing lists that said "Kill it with fire!" Though I can't find that email anymore. I may have deleted it.

kinleyd · 2012-10-31 04:19:29

Thanks WonderWoofy. I couldn't find anything in my /etc folders, but found a number of .service files in /lib/systemd/system. I would be grateful for any definitive pointers as to which location the symlinks are in, or which symlinks I can safely delete to remove the inactive/dead services.

Last edited by kinleyd (2012-10-31 04:20:31)

WonderWoofy · 2012-10-31 04:57:35

It would be a symlink in one of the *.target.wants folders. Enable something that isn't alread enabled, and you will see that the command actually just symlinks the given service into the appropriate folder as defined in the [Install] section of the .service file itself. So you would be looking in /etc/systemd/system or /usr/lib/systemd/system or /run/systemd/system. Though the /run folder is volatile, so it probably is not going to be there.

I have been running without consolekit for maybe two months now. I had been using a polkit patched by tomegun that would work with either logind or consolekit. Then I switched to the testing repo's consolekit. Then I though hey, what the hell, I'll just try the testing repo. I must say, so far I am impressed with how smooth the testing repo has been.

kinleyd · 2012-10-31 05:02:32

Thanks a lot. I will try it out the way you suggested. I won't be as bleeding edge as you, but I'll try not to be too far behind. ;)

brain0 · 2012-10-31 09:08:08

I can't find any consolekit-related services on my system.

SoleSoul · 2012-10-31 10:34:59

This systemd is funny, it replaces everything In the end we would call our systems GNU/SystemD.

Last edited by SoleSoul (2012-10-31 10:35:15)

dolby · 2012-10-31 12:21:53

Hopefully it will replace the GNU part, not the Linux one.

kinleyd · 2012-10-31 13:18:54

@brain0: It's pretty weird: I had all these as inactive/dead services when I checked after removing consolekit (and rebooting, etc):

auditd, consolekit, plymouth-quit-wait, plymouth-start, rc-local, syslog.

Later in the day I installed kernel 3.6.4 and rebooted, and all remained in the list of inactive/dead services except consolekit, which was gone. Which is good, in a way, though I still have to hunt down the others and remove them.

WonderWoofy · 2012-10-31 13:32:07

@brain0, I think the only reason why they would still be showing up is if you were to enable them to have them load early. Since they were always loaded anyway, some users were apparnetly having delays with it being pulled as a dep instead of being specified as a startup service.

@ kinleyd, I noticed those things as well. If you don't plan on using things like plymouthd or auditd or a real syslog (in addition to the journal), you can simply mask them. Do this by either using systemctl mask or simply symlinking the units in /etc/systemd/system to /dev/null.

kinleyd · 2012-10-31 13:34:54

Thanks, WonderWoofy, that's very helpful. I'll try the 'systemctl mask' route and see how it goes.

Last edited by kinleyd (2012-10-31 15:17:48)

brain0 · 2012-10-31 14:26:07

WonderWoofy wrote:

@ kinleyd, I noticed those things as well. If you don't plan on using things like plymouthd or auditd or a real syslog (in addition to the journal), you can simply mask them. Do this by either using systemctl mask or simply symlinking the units in /etc/systemd/system to /dev/null.

There is no need to mask those services - they don't exist. There are some references to them in other units, that's why they show up. If you want a nice overview over your system, try

systemctl

or

systemctl list-unit-files

kinleyd · 2012-10-31 15:12:53

@brain0: You are right, neither systemctl nor 'systemctl list-unit-files' shows the errors I mentioned. However, 'systemctl --all' does reflect them, and that's the issue. Having seen it, it'd be nice to fix it (ie. remove the source of the errors, especially if the services don't exist) -- if it isn't too complicated.

Last edited by kinleyd (2012-10-31 15:14:41)

brain0 · 2012-10-31 16:22:23

Let me give you an example:

$ systemctl --all|grep error
auditd.service                                                                                                 error  inactive dead          auditd.service
plymouth-quit-wait.service                                                                                     error  inactive dead          plymouth-quit-wait.service
plymouth-start.service                                                                                         error  inactive dead          plymouth-start.service
rc-local.service                                                                                               error  inactive dead          rc-local.service
syslog.service                                                                                                 error  inactive dead          syslog.service

Let's look at rc-local.service (which doesn't exist on Arch):

$ grep rc-local.service /usr/lib/systemd/system/* 2>/dev/null 
/usr/lib/systemd/system/autovt@.service:After=rc-local.service
/usr/lib/systemd/system/console-getty.service:After=rc-local.service
/usr/lib/systemd/system/console-shell.service:After=rc-local.service
/usr/lib/systemd/system/getty@.service:After=rc-local.service
/usr/lib/systemd/system/serial-getty@.service:After=rc-local.service

As you can see, there are some After= orderings on this service. This is why systemd tries to load the service. This is not a problem, since After= does not imply a dependency, just an ordering. If you don't have the service (or have it but don't enable it), this is harmless.

These errors won't go away - you will always have units that have After= or Before= on services you don't have installed. There isn't even anything to fix. If you want to see if a real error happened on your system, the following command is your friend:

systemctl --failed

kinleyd · 2012-11-01 05:29:29

Yes, I had figured out the '| grep error' and '--failed' command options, but your explanation of systemd's orderings was very clear. Thanks brain0.

Arch Linux

#1 2012-10-30 23:04:33

Has consolekit not been replaced yet?

#2 2012-10-30 23:05:17

Re: Has consolekit not been replaced yet?

#3 2012-10-30 23:06:48

Re: Has consolekit not been replaced yet?

#4 2012-10-30 23:10:30

Re: Has consolekit not been replaced yet?

#5 2012-10-31 01:20:25

Re: Has consolekit not been replaced yet?

#6 2012-10-31 01:40:35

Re: Has consolekit not been replaced yet?

#7 2012-10-31 03:33:49

Re: Has consolekit not been replaced yet?

#8 2012-10-31 04:07:47

Re: Has consolekit not been replaced yet?

#9 2012-10-31 04:19:29

Re: Has consolekit not been replaced yet?

#10 2012-10-31 04:57:35

Re: Has consolekit not been replaced yet?

#11 2012-10-31 05:02:32

Re: Has consolekit not been replaced yet?

#12 2012-10-31 09:08:08

Re: Has consolekit not been replaced yet?

#13 2012-10-31 10:34:59

Re: Has consolekit not been replaced yet?

#14 2012-10-31 12:21:53

Re: Has consolekit not been replaced yet?

#15 2012-10-31 13:18:54

Re: Has consolekit not been replaced yet?

#16 2012-10-31 13:32:07

Re: Has consolekit not been replaced yet?

#17 2012-10-31 13:34:54

Re: Has consolekit not been replaced yet?

#18 2012-10-31 14:26:07

Re: Has consolekit not been replaced yet?

#19 2012-10-31 15:12:53

Re: Has consolekit not been replaced yet?

#20 2012-10-31 16:22:23

Re: Has consolekit not been replaced yet?

#21 2012-11-01 05:29:29

Re: Has consolekit not been replaced yet?

Board footer