[ClusterLabs] Error performing operation: Argument list too long

[Andrei Borzenkov]

06.12.2016 20:41, Jan Pokorný пишет:
> On 06/12/16 09:44 -0600, Ken Gaillot wrote:
>> On 12/05/2016 02:29 PM, Shane Lawrence wrote:
>>> I'm experiencing a strange issue with pacemaker. It is unable to check
>>> the status of a systemd resource.
>>>
>>> systemctl shows that the service crashed:

No, it shows that service process exited gracefully without errors.
There is no indication of "crash" in output you posted.

>>> [root at xxxxxxxxxx ~]# systemctl status rsyslog
>>> ● rsyslog.service - System Logging Service
>>>    Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled;
>>> vendor preset: enabled)
>>>    Active: inactive (dead) since Mon 2016-12-05 07:41:11 UTC; 12h ago
>>>      Docs: man:rsyslogd(8)
>>>            http://www.rsyslog.com/doc/
>>>  Main PID: 22703 (code=exited, status=0/SUCCESS)
>>>
>>> Dec 02 21:41:41 xxxxxxxxxx.xxxx.xxxx.xx systemd[1]: Starting Cluster
>>> Controlled rsyslog...
>>> Dec 02 21:41:41 xxxxxxxxxx.xxxx.xxxx.xx systemd[1]: Started Cluster
>>> Controlled rsyslog.
>>> Dec 05 07:41:08 xxxxxxxxxx.xxxx.xxxx.xx systemd[1]: Stopping System
>>> Logging Service...
>>> Dec 05 07:41:11 xxxxxxxxxx.xxxx.xxxx.xx systemd[1]: Stopped System
>>> Logging Service.
>>> Dec 05 07:41:40 xxxxxxxxxx.xxxx.xxxx.xx systemd[1]: Stopped System
>>> Logging Service.
>>>
>>> Attempting to view the status through Pacemaker shows:
>>> [root at xxxxxxxxxx ~]# crm_resource --force-check -V -r rsyslog
>>> Error performing operation: Argument list too long
>>> [root at xxxxxxxxxx ~]# pcs resource debug-monitor rsyslog --full
>>> Error performing operation: Argument list too long
>>>
>>> The problem seems to be resolved (temporarily) by restarting corosync
>>> and then starting the cluster again.
>>>
>>> Has anyone else experienced this?
>>
>> That is odd behavior. You may want to open a bug report at
>> bugs.clusterlabs.org and attach your configuration and logs.
>>
>> On Linux, the system error number for "Argument list too long" is the
>> same as the OCF monitor status "Not running", so I suspect that it's a
>> display issue rather than an actual error, but I'm not sure.
>>
>> Then the question would just be why is rsyslog stopping.
> 
> Even more that "Cluster Controlled rsyslog has been started" while
> "System Logging Service" is being stopped.  Could it be a result
> of a namespace/daemon/service clash of some kind?
> 

systemctl status does simplistic match by unit name, rsyslog.service in
this case, to show logs. It is entirely possible that between unit start
and unit stop its definition was changed and systemd reloaded (which
often happens implicitly during packages install at the very least).
This would explain such behavior.

дек 07 06:45:59 bor-Latitude-E5450 systemd[1]: Starting Before reload foo...
дек 07 06:46:09 bor-Latitude-E5450 systemd[1]: Stopped Before reload foo.
дек 07 06:46:35 bor-Latitude-E5450 systemd[1]: Started Before reload foo.

Edit Description of unit and do systemctl daemon-reload

дек 07 06:47:01 bor-Latitude-E5450 systemd[1]: Stopping After reload foo...
дек 07 06:47:01 bor-Latitude-E5450 systemd[1]: Stopped After reload foo.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20161207/f2c60ffa/attachment-0003.sig>