FS#39583 - [acpid] cannot open input layer error

Attached to Project: Community Packages
Opened by Francesco Antonacci (punkeroso) - Saturday, 22 March 2014, 08:59 GMT
Last edited by Sébastien Luttringer (seblu) - Sunday, 23 November 2014, 23:39 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Sébastien Luttringer (seblu)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No

Details

I've enabled acpid service but, once the pc starts, some key doesn't work.

If show the service status i get:

acpid[163]: cannot open input layer
acpid[163]: inotify_add_watch() failed: No such file or directory (2)

If I restart the service, everything works just fine.

I guess that the service starts too soon so that some file is not yet present.

Additional info:
* package version(s)

acpid 2.0.22-1

* config and/or log files etc.

no

Steps to reproduce:

Just enable acpid service, restart the pc and show service status.
This task depends upon

Closed by  Sébastien Luttringer (seblu)
Sunday, 23 November 2014, 23:39 GMT
Reason for closing:  Fixed
Additional comments about closing:  acpid 2.0.22-3
Comment by Want to Conceal (brainwave) - Thursday, 26 June 2014, 15:26 GMT
I faced the same problem. Having configured my acpid to change brightness depending upon brightness keys, it did not worked until I closed and restarted acpid. Basing on this behaviour, I thought if we can delay the starting of acpid, it should work.

Workaround -> In the config file, under [Unit] section, adding

After=multi-user.target

and under [Service] adding

Type=simple

Enabled acpid to function as expected.
Comment by Sébastien Luttringer (seblu) - Saturday, 23 August 2014, 23:26 GMT
Is the problem still here with acpid 2.0.23?
Comment by Francesco Antonacci (punkeroso) - Monday, 25 August 2014, 17:35 GMT
Unfortunately yes, for me the issue is still there even with the latest acpid version...
Comment by Sébastien Luttringer (seblu) - Tuesday, 26 August 2014, 08:55 GMT
the changelog was so tiny... but could you report that upstream?
Comment by Francesco Antonacci (punkeroso) - Tuesday, 26 August 2014, 10:37 GMT
Done https://sourceforge.net/p/acpid2/tickets/3
Comment by Sébastien Luttringer (seblu) - Tuesday, 26 August 2014, 22:50 GMT
Thanks, I will close this one and to let discussion continue upstream.
Comment by Francesco Antonacci (punkeroso) - Sunday, 19 October 2014, 13:51 GMT
  • Field changed: Percent Complete (100% → 0%)
Editing the .service file like explained in first response, actually solved the problem.
The .service file are not provided by upstream (http://sourceforge.net/p/acpid2/tickets/3/), so you should update the packege with the new .service file.

Regards
Comment by Sébastien Luttringer (seblu) - Sunday, 19 October 2014, 15:04 GMT
Add After=multi-user.target to acpid.service makes no sense, acpid is pulled by multi-user.target.

I added a comment 8 days ago to upstream ticket. W&S
Comment by Francesco Antonacci (punkeroso) - Sunday, 19 October 2014, 20:15 GMT
Simply by adding:
Type=idle

to the default .service file, seems to solve the problem (so, without After=multi-user.target).

As man systemd.service explains, idle "is very similar to simple, however actual execution of the service binary is delayed until all jobs are dispatched. This may be used to avoid interleaving of output of shell services with the status output on the console."
Comment by Sébastien Luttringer (seblu) - Sunday, 19 October 2014, 20:52 GMT
Francesco, acpid try to open a layer which is not available when it starts. What you suggest is to delay acpid start, hoping that the layer will be ready later. We should find a way to know when this "layer" is ready and make acpid starts after. Not just rely on a race condition.
Comment by Francesco Antonacci (punkeroso) - Monday, 20 October 2014, 08:06 GMT
If there's something I can do/try to know which is the unavailable layer, please let me know.
Thanks
Comment by Henrik Bendt (heben2) - Wednesday, 22 October 2014, 20:56 GMT
I have had this problem for years; great to finally have a solution.
Comment by Sébastien Luttringer (seblu) - Thursday, 23 October 2014, 20:03 GMT
@punkeroso: I sent an email to the maintainer right now.
Comment by Sébastien Luttringer (seblu) - Friday, 24 October 2014, 23:57 GMT
I read the acpid2 code and it's because /dev/input/event* files are not yet created by udevd.

I added a Require=systemd-udev-settle.service to fix the issue.
Comment by Sébastien Luttringer (seblu) - Sunday, 23 November 2014, 23:38 GMT
I added After=systemd-udev-settle.service because, Require= doesn't imply After.

Loading...