[gentoo-user] Unlocking Plasma desktop in Gentoo without systemd

[gentoo-user] Unlocking Plasma desktop in Gentoo without systemd

[Mick]

[-- Attachment #1: Type: text/plain, Size: 826 bytes --]

I started a plasma session and after some period of input inactivity I noticed 
the screen blanked out.  Later on I moved the mouse and to my surprise I 
obtained this message:
*********************
"The screen locker is broken and unlocking is not possible anymore.
In order to unlock switch to a virtual terminal (e.g. Ctrl+Alt+F2),
log in and execute the command:

loginctl unlock-sessions

Afterwards switch back to the running session (Ctrl+Alt+F7)."
*********************

Given this is a non-systemd Gentoo installation and I intend to keep it this 
way as long as reasonably practicable, what should I instruct the user to do 
to recover their current plasma session?

If this is a default Gentoo installation with openrc, why does a default 
plasma desktop screenlocker comes up with this nonsense?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Unlocking Plasma desktop in Gentoo without systemd

[Stroller]

> On 11 Sep 2017, at 18:49, Mick <michaelkintzios@gmail.com> wrote:
> 
> … 
> "The screen locker is broken and unlocking is not possible anymore.
> In order to unlock switch to a virtual terminal (e.g. Ctrl+Alt+F2),
> log in and execute the command:
> 
> loginctl unlock-sessions
> 
> ...
> 
> If this is a default Gentoo installation with openrc, why does a default 
> plasma desktop screenlocker comes up with this nonsense?

Is it possible some of your KDE components were emerged with USE="systemd"?

Try something like `emerge -pN world`?

Stroller.

Re: [gentoo-user] Unlocking Plasma desktop in Gentoo without systemd

[Mick]

[-- Attachment #1: Type: text/plain, Size: 2468 bytes --]

On Monday, 11 September 2017 19:18:30 BST Stroller wrote:
> > On 11 Sep 2017, at 18:49, Mick <michaelkintzios@gmail.com> wrote:
> > 
> > …
> > "The screen locker is broken and unlocking is not possible anymore.
> > In order to unlock switch to a virtual terminal (e.g. Ctrl+Alt+F2),
> > log in and execute the command:
> > 
> > loginctl unlock-sessions
> > 
> > ...
> > 
> > If this is a default Gentoo installation with openrc, why does a default
> > plasma desktop screenlocker comes up with this nonsense?
> 
> Is it possible some of your KDE components were emerged with USE="systemd"?
> 
> Try something like `emerge -pN world`?
> 
> Stroller.

Thanks Stroller, but no, this PC never had any systemd component, on purpose:

# emerge -pN world

These are the packages that would be merged, in order:

Calculating dependencies... done!


I had disabled USE flag 'systemd' in make.conf as soon as this flag was 
established:

$ euse -I systemd
global use flags (searching: systemd)
************************************************************

local use flags (searching: systemd)
************************************************************
[- c    ] systemd (dev-qt/qtcore):
Enable native journald logging support

[- c    ] systemd (media-sound/pulseaudio):
Build with sys-apps/systemd support to replace standalone ConsoleKit.

[- c    ] systemd (sys-apps/accountsservice):
Use sys-apps/systemd instead of sys-auth/consolekit for session tracking

[- c    ] systemd (sys-apps/busybox):
Support systemd

[- c    ] systemd (sys-apps/dbus):
Build with sys-apps/systemd at_console support

[- c    ] systemd (sys-auth/pambase):
Use pam_systemd module to register user sessions in the systemd control group 
hierarchy.

[- c    ] systemd (sys-auth/polkit):
Use sys-apps/systemd instead of sys-auth/consolekit for session tracking

[- c    ] systemd (sys-fs/udisks):
Support sys-apps/systemd's logind

The interesting thing is I never enabled screen locking, so plasma ought to be 
running with default settings.  If such a setting causes the session to become 
inaccessible it should have been disabled by default.  There may have been a 
warning about it in the past, but I can't recall it.

The funny thing was the user thought her machine was being hacked!  o_O

I tried to pacify her by explaining that without systemd stack the attack 
surface should be smaller.  ;-p
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Unlocking Plasma desktop in Gentoo without systemd

[Jigme Datse Yli-RAsku]

[-- Attachment #1.1: Type: text/plain, Size: 2076 bytes --]

I had a similar (if not identical problem).  This solution is a
"difficult" solution, the reason I experienced this (if I understand)
was that I was running KDE at the same time I was updating KDE.  I can't
remember if I simply rebooted, or if all it took was logging out, and
logging back in.  Even if I had rebooted, the *most* that should be
required is restarting X, which if you are running XDM may require
restarting XDM, or as stated, simply logging out and logging back in
(but that might not be possible from KDE running in this broken mode).
It should happen relatively infrequently.

If you are doing unattended updates, you are likely to run into this
kind of problem from time to time.  I do not recommend it except for
"security" updates, which I don't believe there is an automated process
in Gentoo to do.  Ie. I don't believe Portage flags updates as
"security" updates in any way, so a single command of "emerge --update
--security-only @word" (to my knowledge) isn't really a possibility.

Though, also, I haven't been following recent discussions that closely,
and I only recently returned to Gentoo after about 10 years away.

On 09/11/2017 10:49 AM, Mick wrote:
> I started a plasma session and after some period of input inactivity I noticed 
> the screen blanked out.  Later on I moved the mouse and to my surprise I 
> obtained this message:
> *********************
> "The screen locker is broken and unlocking is not possible anymore.
> In order to unlock switch to a virtual terminal (e.g. Ctrl+Alt+F2),
> log in and execute the command:
> 
> loginctl unlock-sessions
> 
> Afterwards switch back to the running session (Ctrl+Alt+F7)."
> *********************
> 
> Given this is a non-systemd Gentoo installation and I intend to keep it this 
> way as long as reasonably practicable, what should I instruct the user to do 
> to recover their current plasma session?
> 
> If this is a default Gentoo installation with openrc, why does a default 
> plasma desktop screenlocker comes up with this nonsense?
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 939 bytes --]

Re: [gentoo-user] Unlocking Plasma desktop in Gentoo without systemd

[Mick]

On Monday, 11 September 2017 19:27:02 BST Jigme Datse Yli-RAsku wrote:
> I had a similar (if not identical problem).  This solution is a
> "difficult" solution, the reason I experienced this (if I understand)
> was that I was running KDE at the same time I was updating KDE.  

No the user started a Plasma session after booting up the PC and while no 
updates were being performed.


> I can't
> remember if I simply rebooted, or if all it took was logging out, and
> logging back in.  Even if I had rebooted, the *most* that should be
> required is restarting X, which if you are running XDM may require
> restarting XDM, or as stated, simply logging out and logging back in
> (but that might not be possible from KDE running in this broken mode).
> It should happen relatively infrequently.

I can login and restart xdm, but I fear the user may lose some the work being 
performed at the time.  I may end up doing this, but not if there is a way to 
recover the session.  Strangely, I can't see any relevant screenlock process I 
could stop from the console.  :-(
-- 
Regards,
Mick

Re: [gentoo-user] Unlocking Plasma desktop in Gentoo without systemd

[Dan Johansson]

On 11.09.2017 21:04, Mick wrote:
> On Monday, 11 September 2017 19:27:02 BST Jigme Datse Yli-RAsku wrote:
>> I had a similar (if not identical problem).  This solution is a
>> "difficult" solution, the reason I experienced this (if I understand)
>> was that I was running KDE at the same time I was updating KDE.  
> 
> No the user started a Plasma session after booting up the PC and while no 
> updates were being performed.
> 
> 
>> I can't
>> remember if I simply rebooted, or if all it took was logging out, and
>> logging back in.  Even if I had rebooted, the *most* that should be
>> required is restarting X, which if you are running XDM may require
>> restarting XDM, or as stated, simply logging out and logging back in
>> (but that might not be possible from KDE running in this broken mode).
>> It should happen relatively infrequently.
> 
> I can login and restart xdm, but I fear the user may lose some the work being 
> performed at the time.  I may end up doing this, but not if there is a way to 
> recover the session.  Strangely, I can't see any relevant screenlock process I 
> could stop from the console.  :-(
> 

Try this:

# Get Session-ID
sesid=$(ck-list-sessions | egrep "(Session[0-9]:|x11-display = ':0')" |
grep -B 2 "x11-display = ':0'" | grep "Session" | cut -d":" -f1)

# Unlock
sudo dbus-send --system --print-reply
--dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/${sesid}
org.freedesktop.ConsoleKit.Session.Unlock


-- 
Dan Johansson
***************************************************
This message is printed on 100% recycled electrons!
***************************************************

Re: [gentoo-user] Unlocking Plasma desktop in Gentoo without systemd

[Mick]

[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]

On Monday, 11 September 2017 20:27:02 BST Dan Johansson wrote:
> On 11.09.2017 21:04, Mick wrote:
> > On Monday, 11 September 2017 19:27:02 BST Jigme Datse Yli-RAsku wrote:
> >> I had a similar (if not identical problem).  This solution is a
> >> "difficult" solution, the reason I experienced this (if I understand)
> >> was that I was running KDE at the same time I was updating KDE.
> > 
> > No the user started a Plasma session after booting up the PC and while no
> > updates were being performed.
> > 
> >> I can't
> >> remember if I simply rebooted, or if all it took was logging out, and
> >> logging back in.  Even if I had rebooted, the *most* that should be
> >> required is restarting X, which if you are running XDM may require
> >> restarting XDM, or as stated, simply logging out and logging back in
> >> (but that might not be possible from KDE running in this broken mode).
> >> It should happen relatively infrequently.
> > 
> > I can login and restart xdm, but I fear the user may lose some the work
> > being performed at the time.  I may end up doing this, but not if there
> > is a way to recover the session.  Strangely, I can't see any relevant
> > screenlock process I could stop from the console.  :-(
> 
> Try this:
> 
> # Get Session-ID
> sesid=$(ck-list-sessions | egrep "(Session[0-9]:|x11-display = ':0')" |
> grep -B 2 "x11-display = ':0'" | grep "Session" | cut -d":" -f1)
> 
> # Unlock
> sudo dbus-send --system --print-reply
> --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/${sesid}
> org.freedesktop.ConsoleKit.Session.Unlock

Thank you All, the suggestion to unlock the sessionID worked!

So, KDE is now becoming good as Gnome in becoming entwined with systemd.  I 
can see myself ending up in working on VTs only soon!  ;-p

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Unlocking Plasma desktop in Gentoo without systemd

[Daniel Frey]

On 09/11/2017 10:49 AM, Mick wrote:
> I started a plasma session and after some period of input inactivity I noticed
> the screen blanked out.  Later on I moved the mouse and to my surprise I
> obtained this message:
> *********************
> "The screen locker is broken and unlocking is not possible anymore.
> In order to unlock switch to a virtual terminal (e.g. Ctrl+Alt+F2),
> log in and execute the command:
> 
> loginctl unlock-sessions
> 
> Afterwards switch back to the running session (Ctrl+Alt+F7)."
> *********************
> 
> Given this is a non-systemd Gentoo installation and I intend to keep it this
> way as long as reasonably practicable, what should I instruct the user to do
> to recover their current plasma session?

Are you updating KDE? I always run into this issue when updating KDE, so 
I now turn off the screen lock before I commence updating.

> 
> If this is a default Gentoo installation with openrc, why does a default
> plasma desktop screenlocker comes up with this nonsense?
> 

Because KDE expects people to use systemd, a bug was raised regarding 
this issue, and the developers basically said you're on your own 
(RESOLVED: WONTFIX):

https://bugs.kde.org/show_bug.cgi?id=360489

According to a comment in the bug, you can try to figure out which 
session it is (ck-list-sessions) and look for the X11 display property 
set. This will not work (or could be difficult) if you have several 
users using KDE at the same time and can't tell the sessions apart.

Once you figure that out, remember the session name and:

# su -c 'dbus-send --system --print-reply \
--dest="org.freedesktop.ConsoleKit" \
  /org/freedesktop/ConsoleKit/<session name> \
org.freedesktop.ConsoleKit.Session.Unlock'

This worked on my laptop running openrc. I now just disable the locker 
before doing updates.

Dan

[gentoo-user] Re: Unlocking Plasma desktop in Gentoo without systemd

[Michael Palimaka]

On 09/12/2017 05:04 AM, Daniel Frey wrote:
> According to a comment in the bug, you can try to figure out which
> session it is (ck-list-sessions) and look for the X11 display property
> set. This will not work (or could be difficult) if you have several
> users using KDE at the same time and can't tell the sessions apart.
> 
> Once you figure that out, remember the session name and:
> 
> # su -c 'dbus-send --system --print-reply \
> --dest="org.freedesktop.ConsoleKit" \
>  /org/freedesktop/ConsoleKit/<session name> \
> org.freedesktop.ConsoleKit.Session.Unlock'
> 

If there a nice way to wrap this up in a script I'd be interesting in
shipping this for non-logind systems.

Another option is sys-auth/elogind, which provides the logind interface
and tools (like loginctl) for non-systemd systems. This is what I've
been testing with OpenRC for some time.

I read that ConsoleKit is also supporting the logind dbus interface now.
This would in theory make it easy to create a tool to unlock the
session, but I haven't had a chance to test it yet.

Re: [gentoo-user] Re: Unlocking Plasma desktop in Gentoo without systemd

[Mick]

[-- Attachment #1: Type: text/plain, Size: 1668 bytes --]

On Tuesday, 12 September 2017 13:13:32 BST Michael Palimaka wrote:
> On 09/12/2017 05:04 AM, Daniel Frey wrote:
> > According to a comment in the bug, you can try to figure out which
> > session it is (ck-list-sessions) and look for the X11 display property
> > set. This will not work (or could be difficult) if you have several
> > users using KDE at the same time and can't tell the sessions apart.
> > 
> > Once you figure that out, remember the session name and:
> > 
> > # su -c 'dbus-send --system --print-reply \
> > --dest="org.freedesktop.ConsoleKit" \
> > 
> >  /org/freedesktop/ConsoleKit/<session name> \
> > 
> > org.freedesktop.ConsoleKit.Session.Unlock'
> 
> If there a nice way to wrap this up in a script I'd be interesting in
> shipping this for non-logind systems.
> 
> Another option is sys-auth/elogind, which provides the logind interface
> and tools (like loginctl) for non-systemd systems. This is what I've
> been testing with OpenRC for some time.
> 
> I read that ConsoleKit is also supporting the logind dbus interface now.
> This would in theory make it easy to create a tool to unlock the
> session, but I haven't had a chance to test it yet.

I think if Plasma shipped with screenlock unset as a default this problem 
would not exist for non-systemd set ups.  I disabled Plasma's screenlock and 
after after some time of inactivity eventually DPMS kicks in and the monitors 
go into power saving mode.  This negates for needing special scripts elogind 
or anything else KDE/Plasma never needed before now.

Nevertheless, the suggestions for using dbus-send were useful for getting me 
out of a hole.  Thanks again! :-)
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Re: Unlocking Plasma desktop in Gentoo without systemd

[J. Roeleveld]

On Tuesday, September 12, 2017 2:13:32 PM CEST Michael Palimaka wrote:
> On 09/12/2017 05:04 AM, Daniel Frey wrote:
> > According to a comment in the bug, you can try to figure out which
> > session it is (ck-list-sessions) and look for the X11 display property
> > set. This will not work (or could be difficult) if you have several
> > users using KDE at the same time and can't tell the sessions apart.
> > 
> > Once you figure that out, remember the session name and:
> > 
> > # su -c 'dbus-send --system --print-reply \
> > --dest="org.freedesktop.ConsoleKit" \
> > 
> >  /org/freedesktop/ConsoleKit/<session name> \
> > 
> > org.freedesktop.ConsoleKit.Session.Unlock'
> 
> If there a nice way to wrap this up in a script I'd be interesting in
> shipping this for non-logind systems.

There is:
joost@eve ~ $ cat /usr/local/bin/unlock-screens.sh 
ck-list-sessions | grep Session | sed 's/\(.*\):/dbus-send --system --print-
reply --dest\=\"org.freedesktop.ConsoleKit\" \/org\/freedesktop\/ConsoleKit\/
\1 org.freedesktop.ConsoleKit.Session.Unlock/' | sh

joost@eve ~ $ cat /usr/local/bin/lock-screens.sh 
ck-list-sessions | grep Session | sed 's/\(.*\):/dbus-send --system --print-
reply --dest\=\"org.freedesktop.ConsoleKit\" \/org\/freedesktop\/ConsoleKit\/
\1 org.freedesktop.ConsoleKit.Session.Lock/' | sh


I build these when I encountered this same issue nearly a year ago. I run them 
as "root" and they will (un)lock ALL X-sessions.

> Another option is sys-auth/elogind, which provides the logind interface
> and tools (like loginctl) for non-systemd systems. This is what I've
> been testing with OpenRC for some time.

If it works better, I have no issue with it being pulled in.

> I read that ConsoleKit is also supporting the logind dbus interface now.
> This would in theory make it easy to create a tool to unlock the
> session, but I haven't had a chance to test it yet.

Better solutions are always welcome.

--
Joost

Re: [gentoo-user] Re: Unlocking Plasma desktop in Gentoo without systemd

[Daniel Frey]

[-- Attachment #1: Type: text/plain, Size: 1607 bytes --]

On 09/12/17 05:13, Michael Palimaka wrote:
> On 09/12/2017 05:04 AM, Daniel Frey wrote:
>> According to a comment in the bug, you can try to figure out which
>> session it is (ck-list-sessions) and look for the X11 display property
>> set. This will not work (or could be difficult) if you have several
>> users using KDE at the same time and can't tell the sessions apart.
>>
>> Once you figure that out, remember the session name and:
>>
>> # su -c 'dbus-send --system --print-reply \
>> --dest="org.freedesktop.ConsoleKit" \
>>  /org/freedesktop/ConsoleKit/<session name> \
>> org.freedesktop.ConsoleKit.Session.Unlock'
>>
> 
> If there a nice way to wrap this up in a script I'd be interesting in
> shipping this for non-logind systems.
> 
> Another option is sys-auth/elogind, which provides the logind interface
> and tools (like loginctl) for non-systemd systems. This is what I've
> been testing with OpenRC for some time.
> 
> I read that ConsoleKit is also supporting the logind dbus interface now.
> This would in theory make it easy to create a tool to unlock the
> session, but I haven't had a chance to test it yet.
> 

Well, I forgot to disable my screen locker during an update and got bit
by this again. It's a pain typing it manually (especially when you run a
monitor in portrait mode.)

I had some time and put together a general-purpose bash script. A note
of warning, I'm not an expert at bash by any means, but I was able to
test this several ways as I haven't restarted my computer yet.

I'll attach it if someone else wants to try it out. It's simply called
ck-unlock-session.

Dan

[-- Attachment #2: ck-unlock-session --]
[-- Type: text/plain, Size: 7219 bytes --]

#!/bin/sh

# This script is to make unlocking using OpenRC/Consolekit easier when the KDE Screenlocker breaks.
#
# Version: 0.1
# Date written: February 2, 2018
#
# Copyright (C) 2018 Daniel Frey
#
# This script is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This script is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
#
# Some notes:
#   -The switch processing/argument handling is very basic.
#   -This script assumes session names start with "Session" when listing
#    sessions. This is settable via a variable.
#
# Possible actions:
#   -h : Show help screen
#   -l : List current consolekit sessions
#   -u : Unlock specified session (one parameter required - the session name)
#   -a : Attempt to unlock all sessions

# Return code documentation
#
#  0: Script executed normally
#  1: Root access is not present for script
#  2: No arguments passed
#  3: Multiple actions requested, can only do one at a time
#  4: Argument passed was not recognized
#  5: Multiple arguments passed for unlock single session, only one needed
#  6: The argument required for unlocksession() is missing (internal error)

# Return code constants
readonly ERR_NORMAL_OPERATION=0
readonly ERR_NO_ROOT=1
readonly ERR_NO_ARGS=2
readonly ERR_TOO_MANY_ACTIONS=3
readonly ERR_INVALID_ARGUMENTS=4
readonly ERR_TOO_MANY_ARGS=5
readonly ERR_INTERNAL_ARG_MISSING=6

# Action parameter constants
readonly ACTION_NONE=0
readonly ACTION_HELP=1
readonly ACTION_LIST=2
readonly ACTION_UNLOCKALL=3
readonly ACTION_UNLOCK=4

# This is what's used to look for a session via consolekit.
# By default, assume it is prefixed with "Session".
SESSION_SEARCH_PREFIX=Session

# Check to make sure script has root access, if not... abort now!
if [ $EUID -ne 0 ]; then
	echo "This script must be run as root."
	exit $ERR_NO_ROOT
fi

function showhelp () {
        echo "`basename $0`: a script that helps unlock consolekit sessions

Usage: `basename $0` [action] [parameters]

Actions:
        -l : list current sessions available for unlocking 

        -u : unlock session specified as a parameter

        -a : attempt to unlock all current sessions

        -h : this screen

Parameters:
        The -u parameter requires a session name to unlock, use -l to list
	sessions.

Example:

To unlock a single session, use:
  `basename $0` -u Session1

No arguments will show this screen."
}

function listsessions() {
	# Get a list of all sessions, and remove the full colon from the session name
	ALLSESSIONS=`ck-list-sessions | grep -i ^$SESSION_SEARCH_PREFIX | rev | cut -c 2- | rev`

	echo
	echo "Sessions present on this machine, space-delineated:"
	echo
	echo $ALLSESSIONS
	echo
	echo
	echo "Session detail (to help locate a specific session:"
	ck-list-sessions | grep -A 2 -i ^$SESSION_SEARCH_PREFIX
}

function unlocksession () {
	# This function expects one parameter set (the session to unlock.
	# Make sure the parameter exists before continuing.
	if [[ -z ${1} ]]; then echo $ERR_INTERNAL_ARG_MISSING; fi

	echo "Attempting to unlock session $1; messages from dbus are not suppressed."

	# Finally, request the unlock.
	dbus-send --system --print-reply --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/$1 org.freedesktop.ConsoleKit.Session.Unlock
}

function unlockallsessions () {
        # Get a list of all sessions, and remove the full colon from the session name
        ALLSESSIONS=`ck-list-sessions | grep -i ^$SESSION_SEARCH_PREFIX | rev | cut -c 2- | rev`

	echo "Attempting to unlock all sessions. Messages from dbus are not suppressed."
	echo
	# Loop through results, attempt to unlock all sessions.
	# Count them and report at the end.
	COUNT=0
	for i in $ALLSESSIONS; do
		dbus-send --system --print-reply --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/$i org.freedesktop.ConsoleKit.Session.Unlock
		let "COUNT+=1"
	done

	echo
	echo "Attempted to unlock $COUNT session(s)."
}

# Start of "main" routine

# Initialize variables:
#     ACTION=default 0; used to make sure more than one action are not
#          specified at the same time. If an invalid argument was passed
#          (e.g. one without the hyphen prefix) it will be caught as well.
ACTION=$ACTION_NONE

# Show help if no arguments provided at all
if  [ $# -eq 0 ]; then showhelp; exit $ERR_NO_ARGS; fi

# Process arguments passed, setting environment appropriately.
# During this check, ensure only one action was requested. This
# script will not do multiple things at a time.
while getopts “hlau:” OPTION
do
        case $OPTION in
                h)      # Help action
                        # Make sure multiple actions are not chosen.
                        if [ $ACTION -ne $ACTION_NONE ]; then echo "You can only declare one action at a time!"; echo ""; showhelp; exit $ERR_TOO_MANY_ACTIONS; fi

                        ACTION=$ACTION_HELP
                        ;;
                l)      # List action
                        # Make sure multiple actions are not chosen.
                        if [ $ACTION -ne $ACTION_NONE ]; then echo "You can only declare one action at a time!"; echo ""; showhelp; exit $ERR_TOO_MANY_ACTIONS; fi

                        ACTION=$ACTION_LIST
                        ;;
                a)      # Enable all USB hubs/devices action
                        # Make sure multiple actions are not chosen.
                        if [ $ACTION -ne $ACTION_NONE ]; then echo "You can only declare one action at a time!"; echo ""; showhelp; exit $ERR_TOO_MANY_ACTIONS; fi

                        ACTION=$ACTION_UNLOCKALL
                        ;;
                u)      # Enable specific hub/device via find command action
                        # Make sure multiple actions are not chosen.
                        if [ $ACTION -ne $ACTION_NONE ]; then echo "You can only declare one action at a time!"; echo ""; showhelp; exit $ERR_TOO_MANY_ACTIONS; fi

                        ACTION=$ACTION_UNLOCK

                        # Save session name passed for later
                        UNLOCKSESSION=$OPTARG
                        ;;
                ?)      # Unknown parameter
                        showhelp
                        exit $ERR_INVALID_ARGUMENTS
                        ;;
        esac
done

# If script reaches this point, only one action was specified, so it is safe
# to continue processing.
case $ACTION in
        $ACTION_HELP)      # help action
                showhelp
                ;;
        $ACTION_LIST)      # list action
                listsessions
                ;;
        $ACTION_UNLOCKALL)      # unlock all sessions
		unlockallsessions
                ;;
        $ACTION_UNLOCK)      # unlock single session
		unlocksession $UNLOCKSESSION
                ;;
	*)
		echo "Unrecognized action."
		echo
		showhelp
		exit $ERR_INVALID_ARGUMENTS
		;;
esac

exit $ERR_NORMAL_OPERATION