Bug 1529253

You can still use rhn-push rhnpush -vvv --channel=epel7-centos7-x86_64 --server=http://localhost/APP --dir=<directory containing .rpms> --force

in order to get some .rpms into the software channel.  You need to use command because the spacewalk server already detects the .rpms on the server.

Remember to add "force_package_upload=1" at the end of /etc/rhn/rhn.conf

And do a rhn-satellite restart for it to take effect.

This a a very sloppy work around at this point.  Is there any update on the status of this bug?

Any news about this issue?

It all ties to a lack of default UTF-8 encoding in postgres.  I ended up doing a complete rebuild (version 2.6...which still had errors without doing the following) by doing these steps:

sudo su postgres
psql
update pg_database set datistemplate=false where datname='template1';
drop database Template1;
create database template1 with owner=postgres encoding='UTF-8' 
	lc_collate='en_US.utf8' lc_ctype='en_US.utf8' template template0;
update pg_database set datistemplate=true where datname='template1';

Then do:

spacewalk-setup

After that, ALL the channels synced once the build was complete.

There is no other option without a fresh install?

Unknown, but since it has to do with the entire DB schema, I would suspect that if you do not re-install, the process for switching schema is going to be quite arduous...unless of course spacwalk releases a new one.

I'm getting a similar error when importing the EPEL

In the reposync log file:
2018/01/18 15:26:37 -04:00 'ascii' codec can't encode character u'\xfc' in position 52: ordinal not in range(128)


In /var/log/rhn/tasko/org1/repo-sync-bunch/ log file I'm seeing:
2018-01-18 15:48:33,308 [DefaultQuartzScheduler_Worker-5] ERROR com.redhat.rhn.taskomatic.task.RepoSyncTask  - Executing a task threw an exception: org.quartz.JobExe$
2018-01-18 15:48:33,310 [DefaultQuartzScheduler_Worker-5] ERROR com.redhat.rhn.taskomatic.task.RepoSyncTask  - Message: Command '[/usr/bin/spacewalk-repo-sync, --cha$
2018-01-18 15:48:33,311 [DefaultQuartzScheduler_Worker-5] ERROR com.redhat.rhn.taskomatic.task.RepoSyncTask  - Cause: null
2018-01-18 15:48:33,319 [DefaultQuartzScheduler_Worker-5] ERROR com.redhat.rhn.taskomatic.task.RepoSyncTask  - Stack trace:org.quartz.JobExecutionException: Command $
        at com.redhat.rhn.taskomatic.task.RhnJavaJob.executeExtCmd(RhnJavaJob.java:103)
        at com.redhat.rhn.taskomatic.task.RepoSyncTask.execute(RepoSyncTask.java:70)
        at com.redhat.rhn.taskomatic.task.RhnJavaJob.execute(RhnJavaJob.java:88)
        at com.redhat.rhn.taskomatic.TaskoJob.execute(TaskoJob.java:186)
        at org.quartz.core.JobRunShell.run(JobRunShell.java:216)
        at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:549)

If this is the same issue stemming from the can't encode character issue, there has to be a way to fix this without starting from scratch.

(In reply to max.diorio from comment #6)
> I'm getting a similar error when importing the EPEL
> 
> In the reposync log file:
> 2018/01/18 15:26:37 -04:00 'ascii' codec can't encode character u'\xfc' in
> position 52: ordinal not in range(128)
> 
> 
> In /var/log/rhn/tasko/org1/repo-sync-bunch/ log file I'm seeing:
> 2018-01-18 15:48:33,308 [DefaultQuartzScheduler_Worker-5] ERROR
> com.redhat.rhn.taskomatic.task.RepoSyncTask  - Executing a task threw an
> exception: org.quartz.JobExe$
> 2018-01-18 15:48:33,310 [DefaultQuartzScheduler_Worker-5] ERROR
> com.redhat.rhn.taskomatic.task.RepoSyncTask  - Message: Command
> '[/usr/bin/spacewalk-repo-sync, --cha$
> 2018-01-18 15:48:33,311 [DefaultQuartzScheduler_Worker-5] ERROR
> com.redhat.rhn.taskomatic.task.RepoSyncTask  - Cause: null
> 2018-01-18 15:48:33,319 [DefaultQuartzScheduler_Worker-5] ERROR
> com.redhat.rhn.taskomatic.task.RepoSyncTask  - Stack
> trace:org.quartz.JobExecutionException: Command $
>         at
> com.redhat.rhn.taskomatic.task.RhnJavaJob.executeExtCmd(RhnJavaJob.java:103)
>         at
> com.redhat.rhn.taskomatic.task.RepoSyncTask.execute(RepoSyncTask.java:70)
>         at
> com.redhat.rhn.taskomatic.task.RhnJavaJob.execute(RhnJavaJob.java:88)
>         at com.redhat.rhn.taskomatic.TaskoJob.execute(TaskoJob.java:186)
>         at org.quartz.core.JobRunShell.run(JobRunShell.java:216)
>         at
> org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:549)
> 
> If this is the same issue stemming from the can't encode character issue,
> there has to be a way to fix this without starting from scratch.

Oracle has a Document about my exact issue, but I don't have an account to view it.  Does anyone know how I can see what the cause/resolution is?
https://support.oracle.com/knowledge/Oracle%20Linux%20and%20Virtualization/2241531_1.html

I now have the same error after a reboot.  Looks like the following applies:
https://cstan.io/?p=11252&lang=en

Here's how to backup, translate ASCII to UTF and restore the PGSQL database:
http://blog.e-shell.org/134

I'm going to give it a shot later so I don't have to fully reinstall SW.

Hi Max,

cool, let us know how it goes. I'm not able to do some tests in the next days due to my flu.

Regards

Vic

Hi all,

Any date for correction related to the original error reported?

Traceback (most recent call last):
  File "/usr/bin/spacewalk-repo-sync", line 257, in <module>
    sys.exit(abs(main() or 0))
  File "/usr/bin/spacewalk-repo-sync", line 240, in main
    elapsed_time, channel_ret_code = sync.sync()
  File "/usr/lib/python2.7/site-packages/spacewalk/satellite_tools/reposync.py", line 475, in sync
    ret = self.import_packages(plugin, repo_id, url)
  File "/usr/lib/python2.7/site-packages/spacewalk/satellite_tools/reposync.py", line 1038, in import_packages
    importer.run()
  File "/usr/lib/python2.7/site-packages/spacewalk/server/importlib/importLib.py", line 664, in run
    self.fix()
  File "/usr/lib/python2.7/site-packages/spacewalk/server/importlib/packageImport.py", line 76, in fix
    self.backend.lookupChecksums(self.checksums)
  File "/usr/lib/python2.7/site-packages/spacewalk/server/importlib/backendOracle.py", line 686, in lookupChecksums
    raise e
spacewalk.server.rhnSQL.sql_base.SQLSchemaError: (99999, 'ERROR:  LOCK TABLE can only be used in transaction blocks', '', InternalError('LOCK TABLE can only be used in transaction blocks\n',))

So I was successful at backing up, converting, reinstalling and restoring the database.  It appears that one the surface, everything is working properly and all data is still there and readable.

I then try to do a reposync on the EPEL repo, and once it gets the number of packages, postgres CPU shoots up to 98% and it sits there.

I even tried to reindex the DB, but that didn't seem to help either.  Going to do some more digging, but I may end up having to reinstall.

This whole issue stems from the dB being set to ascii mode. Check your database to see the encoding.

I noticed that my locale set in the OS was missing a value for the LC_ALL variable.  I believe postgres queues off this variable during install.

[[LAColo] root@la-1pspacewalk ~]# locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

The other thing is if template1 gets redone to UTF8, then this wouldn't be an issue either I don't think.

After rebuilding as UTF-8 I'm still having issues, but only with EPEL

Importing packages:     |##################################################| 99.96%
Importing packages:     |##################################################| 99.98%
Importing packages:     |##################################################| 99.99%
Importing packages:     |##################################################| 100.0%
18:58:13 Linking packages to channel.

2018-01-21 18:58:20,678 [Thread-18452] ERROR com.redhat.rhn.taskomatic.task.RepoSyncTask  - 14:49:41
 42/8534 : kipi-plugins-doc-4.10.0-6.el7.noarch.rpm (failed)
14:49:48 50/8534 : knot-2.6.1-1.el7.x86_64.rpm (failed)
14:49:56 51/8534 : koan-2.8.2-1.el7.noarch.rpm (failed)
14:50:09 57/8534 : koji-1.14.0-1.el7.noarch.rpm (failed)
(All other packages after this point fail.)



Traceback (most recent call last):
  File "/usr/bin/spacewalk-repo-sync", line 257, in <module>
    sys.exit(abs(main() or 0))
  File "/usr/bin/spacewalk-repo-sync", line 240, in main
    elapsed_time, channel_ret_code = sync.sync()
  File "/usr/lib/python2.7/site-packages/spacewalk/satellite_tools/reposync.py", line 475, in sync
    ret = self.import_packages(plugin, repo_id, url)
  File "/usr/lib/python2.7/site-packages/spacewalk/satellite_tools/reposync.py", line 1038, in import_packages
    importer.run()
  File "/usr/lib/python2.7/site-packages/spacewalk/server/importlib/importLib.py", line 664, in run
    self.fix()
  File "/usr/lib/python2.7/site-packages/spacewalk/server/importlib/packageImport.py", line 76, in fix
    self.backend.lookupChecksums(self.checksums)
  File "/usr/lib/python2.7/site-packages/spacewalk/server/importlib/backendOracle.py", line 686, in lookupChecksums
    raise e
spacewalk.server.rhnSQL.sql_base.SQLSchemaError: (99999, 'ERROR:  LOCK TABLE can only be used in transaction blocks', '', InternalError('LOCK TABLE can only be used in transaction blocks\n',))

2018-01-21 18:58:20,989 [DefaultQuartzScheduler_Worker-3] ERROR com.redhat.rhn.taskomatic.task.RepoSyncTask  - Executing a task threw an exception: org.quartz.JobExecutionException
2018-01-21 18:58:20,989 [DefaultQuartzScheduler_Worker-3] ERROR com.redhat.rhn.taskomatic.task.RepoSyncTask  - Message: Command '[/usr/bin/spacewalk-repo-sync, --channel, ieeegs_epel_rhel7_x86_64, --type, yum]'
exited with error code 1
2018-01-21 18:58:20,989 [DefaultQuartzScheduler_Worker-3] ERROR com.redhat.rhn.taskomatic.task.RepoSyncTask  - Cause: null
2018-01-21 18:58:21,007 [DefaultQuartzScheduler_Worker-3] ERROR com.redhat.rhn.taskomatic.task.RepoSyncTask  - Stack trace:org.quartz.JobExecutionException: Command '[/usr/bin/spacewalk-repo-sync, --channel, iee
egs_epel_rhel7_x86_64, --type, yum]' exited with error code 1
        at com.redhat.rhn.taskomatic.task.RhnJavaJob.executeExtCmd(RhnJavaJob.java:103)
        at com.redhat.rhn.taskomatic.task.RepoSyncTask.execute(RepoSyncTask.java:70)
        at com.redhat.rhn.taskomatic.task.RhnJavaJob.execute(RhnJavaJob.java:88)
        at com.redhat.rhn.taskomatic.TaskoJob.execute(TaskoJob.java:186)
        at org.quartz.core.JobRunShell.run(JobRunShell.java:216)
        at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:549)

Problem solved after a fresh install. 

It was necessary previously initialize database as refereed on link: https://cstan.io/?p=11252&lang=en


» LANG=en_US.utf8 postgresql-setup initdb

» spacewalk-setup

EPEL sycng was done without any problem.

A complete uninstall and re-install was required.  A simple backup, change encoding and restore was not enough.

The key was before the reinstall, I did:
export LC_ALL=en-US.UTF-8

Once I did this, postgres installed in UTF8 encoding instead of ASCII/C and everything went very smoothly.

Sounds like there either needs to be a check of the locale settings, or a force of the postgres install to use UTF8.

Having this same issue after upgrading from 2.4 to 2.7 on Oracle Linux 6, EPEL won't sync anymore, was working before upgrading to 2.7, but stopped after the upgrade. I also get the same error for the Oracle Linux SCL repo from oracle. 

Are there any solutions that don't involve nuking it from orbit and starting again?

I've been able to dump my database to UTF8, delete my pgsql data directory, and import the data with success. I am using external postgresql-9.5 so might not apply to others having the same issue. These are the steps I did to get it to work. Please note these are a guide, don't blow away your database without actually knowing what you're doing:

# spacewalk-service stop 
# su - postgres
$ pg_dump --blobs --oids --encoding=UTF-8 rhmschema > /path/with/enough/space/rhnschema.utf8.sql
$ exit
# service postgresql-9.5 stop
# cd /var/lib/pgsql/9.5/data
# cp *.conf /tmp
# rm -rf /var/lib/pgsql/9.5/data/*
# export LANG=en_AU.UTF8
# service postgresql-9.5 initdb
# cp /tmp/*.conf /var/lib/pgsql/9.5/data
# service postgresql-9.5 start
# su - postgres
$ createdb -T template0 -E UTF8 rhnschema --locale en_AU.UTF8
$ createlang pltclu rhnschema
$ createuser -P -sDR rhnuser
$ psql --set ON_ERROR_STOP=on rhnschema < /path/with/enough/space/rhnschema.utf8.sql
$ exit
# spacewalk-service start

Afer this EPEL7 and Oracle Linux SCL synced correctly.

Hope this helps someone else.

Ran into this same error with a brand new install using the 2.7 release while attempting to sync Fedora updates.  IMO the install script or documentation needs to be updated to ensure that databases are created with the proper encoding.

We run into the same problem with EPEL ...

Thank you Simon for your hintful and detailed guide for migrating the
pgsql DB to UTF8 - it work's perfect!

Thanks Simon, I just fixed this issue by your workaround.

Spacewalk 2.8 (and older) has already reached it's End Of Life.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before end of life. If you would still like
to see this bug fixed and are able to reproduce it against current version
of Spacewalk 2.9, you are encouraged change the 'version' and re-open it.