Description of problem: On registration attempt an error of: Problem creating unit Consumer How reproducible: 100% if you have a fact > 255 characters in length. Steps to Reproduce: 1. Create a custom fact: $ cat /etc/rhsm/facts/custom.facts {"reallylongfact": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"} 2. Attempt to register Actual results: In candlepin.log: Caused by: org.postgresql.util.PSQLException: ERROR: value too long for type character varying(255) at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2102) ~[postgresql-9.0-801.jdbc4.jar:na] at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1835) ~[postgresql-9.0-801.jdbc4.jar:na] at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257) ~[postgresql-9.0-801.jdbc4.jar:na] at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:500) ~[postgresql-9.0-801.jdbc4.jar:na] at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:388) ~[postgresql-9.0-801.jdbc4.jar:na] at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:334) ~[postgresql-9.0-801.jdbc4.jar:na] at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:133) ~[hibernate-core-4.2.5.Final.jar:4.2.5.Final] ... 66 common frames omitted ====Response Body==== { "displayMessage" : "Problem creating unit Consumer [id = ff80808149bf26a10149c34678970006, type = ConsumerType [id=1000, label=system], getName() = lenovo.local.rm-rf.ca]", "requestUuid" : "d6f3672a-e541-4319-83d4-eaecf50c72f6" } (END) Expected results: I'm not 100% sure what we should do with such a fact, but the system should probably not be blocked from registration. Additional info: Customer hit this with the network.ipv6_address fact. Possible workaround is to add a custom fact with a shorter / dummy value, which should override this. Solving this server side would be ideal for deployed clients. How to solve is another question. We could skip that fact, we could truncate it and try to indicate that. Do not try to use @Size on Consumer.facts annotation, this is limiting the number of facts, not their length.
This is fixed in the master. It was fixed by truncating the fact to 253 characters. Commit hash: fe029aafea0760a7abf317c0558480649d5a975e
*** Bug 1308437 has been marked as a duplicate of this bug. ***
Marking verified!! subscription management server: 2.0.10-1 [root@dhcp35-31 ~]# cat /etc/rhsm/facts/custom.facts {"reallylongfact": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"} [root@dhcp35-31 ~]# subscription-manager register --force The system with UUID eaf6c29e-8003-4edf-9f85-d9dd9401dd4f has been unregistered Registering to: redakkan-candlepin-server.usersys.redhat.com:8443/candlepin Username: admin Password: Organization: admin The system has been registered with ID: 4e0464ec-9d94-4e95-b5b4-fb40f4642cf6
We are seeing this with a host which has a lot of entries under the field "network.ipv6_address" from command "subscription-manager facts" In our case it was caused by IPv6 vnet interfaces on the host which get created by running VMs. We were able to workaround this and register the host by shutting down some of the VMs and rerunning "subscription-manager register".
Hi, Will this fix be included in SAM? There is also another bug [0] open for this behavior reported against SAM directly. [0] https://bugzilla.redhat.com/1310827
This is still an issue and my previous comment can still be used as a temporary workaround. IPv6 can be re-enabled after system registration and things work just find from SAM perspective.
Employee 'fnguyen' has left the company.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days