If you’re making practice on CentOS (as I do) for your RHCE/RHCSA exam you might be installing and working on a couple of VMs running CentOS 7.1 (even though 7.0 should be the reference).
You may have noticed that on that release targetcli tool and its service (target.service) are not working because of a python runtime error:
Installed: targetcli.noarch 0:2.1.fb41-3.el7 Dependency Installed: pyparsing.noarch 0:1.5.6-9.el7 python-configshell.noarch 1:1.1.fb18-1.el7 python-kmod.x86_64 0:0.9-4.el7 python-rtslib.noarch 0:2.1.fb57-3.el7 python-urwid.x86_64 0:1.1.1-3.el7 Complete! [root@server ~]# targetcli Traceback (most recent call last): File "/bin/targetcli", line 24, in <module> from targetcli import UIRoot File "/usr/lib/python2.7/site-packages/targetcli/__init__.py", line 18, in <module> from .ui_root import UIRoot File "/usr/lib/python2.7/site-packages/targetcli/ui_root.py", line 27, in <module> from rtslib_fb import RTSRoot File "/usr/lib/python2.7/site-packages/rtslib_fb/__init__.py", line 24, in <module> from .root import RTSRoot File "/usr/lib/python2.7/site-packages/rtslib_fb/root.py", line 26, in <module> from .target import Target File "/usr/lib/python2.7/site-packages/rtslib_fb/target.py", line 24, in <module> from six.moves import range ImportError: cannot import name range
You will also get an error on target.service:
[root@server ~]# systemctl start target.service
Job for target.service failed. See 'systemctl status target.service' and 'journalctl -xn' for details.
[root@server ~]# journalctl -xn
-- Logs begin at Sun 2016-08-28 22:35:23 CEST, end at Sun 2016-08-28 22:44:29 CEST. --
Aug 28 22:44:29 server.yari.local target[2208]: from six.moves import range
Aug 28 22:44:29 server.yari.local target[2208]: ImportError: cannot import name range
Aug 28 22:44:29 server.yari.local systemd[1]: target.service: main process exited, code=exited, status=1/FAILURE
Aug 28 22:44:29 server.yari.local systemd[1]: Failed to start Restore LIO kernel target configuration.
-- Subject: Unit target.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit target.service has failed.
--
-- The result is failed.
Aug 28 22:44:29 server.yari.local systemd[1]: Unit target.service entered failed state.
By following the trace from the python error it seems clear that root cause is in the six.moves package that is provided by python-six rpm package. On RHEL 7.1 they have a newer version (and of course both targetcli/target work properly on RHEL 7.1, as you can test on AWS if you can still use a free subscription).
Best way to fix that issue is to simply upgrade that package to the newer version available from the repository:
yum update -y python-six
and you will see that target/targetcli will start working like on RHEL 7.1
Dependencies Resolved ========================================================================================================================================== Package Arch Version Repository Size ========================================================================================================================================== Updating: python-six noarch 1.9.0-2.el7 base 29 k Transaction Summary ========================================================================================================================================== Upgrade 1 Package Total download size: 29 k Downloading packages: No Presto metadata available for base python-six-1.9.0-2.el7.noarch.rpm | 29 kB 00:00:00 Running transaction check Running transaction test Transaction test succeeded Running transaction Updating : python-six-1.9.0-2.el7.noarch 1/2 Cleanup : python-six-1.3.0-4.el7.noarch 2/2 Verifying : python-six-1.9.0-2.el7.noarch 1/2 Verifying : python-six-1.3.0-4.el7.noarch 2/2 Updated: python-six.noarch 0:1.9.0-2.el7 Complete! [root@server ~]# targetcli Warning: Could not load preferences file /root/.targetcli/prefs.bin. targetcli shell version 2.1.fb41 Copyright 2011-2013 by Datera, Inc and others. For help on commands, type 'help'. /> ls o- / ......................................................................................................................... [...] o- backstores .............................................................................................................. [...] | o- block .................................................................................................. [Storage Objects: 0] | o- fileio ................................................................................................. [Storage Objects: 0] | o- pscsi .................................................................................................. [Storage Objects: 0] | o- ramdisk ................................................................................................ [Storage Objects: 0] o- iscsi ............................................................................................................ [Targets: 0] o- loopback ......................................................................................................... [Targets: 0] /> exit Global pref auto_save_on_exit=true Last 10 configs saved in /etc/target/backup. Configuration saved to /etc/target/saveconfig.json [root@server ~]# systemctl start target [root@server ~]# systemctl status target target.service - Restore LIO kernel target configuration Loaded: loaded (/usr/lib/systemd/system/target.service; disabled) Active: active (exited) since Sun 2016-08-28 22:50:38 CEST; 5s ago Process: 2367 ExecStart=/usr/bin/targetctl restore (code=exited, status=0/SUCCESS) Main PID: 2367 (code=exited, status=0/SUCCESS) CGroup: /system.slice/target.service Aug 28 22:50:38 server.yari.local systemd[1]: Starting Restore LIO kernel target configuration... Aug 28 22:50:38 server.yari.local systemd[1]: Started Restore LIO kernel target configuration.
Enjoy!
Greetings,
Where or how did you trace the python error? Can you show an example of this, or explain where you found a verbose log?
Thanks
LikeLike
Hey Jon,
targetcli tool sends that stacktrace in the STDERR and refuses to start. When it happened to me, it was simply refusing to run and instead it returned that stacktrace.
LikeLike