Description of problem: /etc/init.d/LCDd start, Oct 22 20:21:08 video LCDd: LCDd version 0.5.3 starting Oct 22 20:21:08 video LCDd: Using Configuration File: /etc/lcdproc/LCDd.conf Oct 22 20:21:08 video LCDd: Listening for queries on 127.0.0.1:13666 Oct 22 20:21:08 video LCDd: hd44780: timing_init() failed (Operation not permitt ed) Oct 22 20:21:08 video LCDd: Driver [hd44780] init failed, return code -1 Oct 22 20:21:08 video LCDd: Could not load driver hd44780 Oct 22 20:21:08 video LCDd: There is no output driver Oct 22 20:21:08 video LCDd: Critical error while initializing, abort. Oct 22 20:21:08 video LCDd[32301]: Az LCDd indÃtása: [SIKERTELEN] Oct 22 20:21:08 video LCDd[32301]: Invalid Screen: X Version-Release number of selected component (if applicable): lcdproc-0.5.3-3.mga2 How reproducible: Every time I attempt to start. Not work, because systemd script not found. I made two script: /lib/systemd/system/LCDd.service ----------------- [Unit] Description=LCDd Service After=syslog.target [Service] Type=forking ExecStart=/usr/sbin/LCDd -c /etc/lcdproc/LCDd.conf ControlGroup=cpu:/ [Install] WantedBy=multi-user.target ----------------- /lib/systemd/system/lcdproc.service ----------------- [Unit] Description=lcdproc Service After=syslog.target LCDd.service [Service] #Type=forking Type=oneshot RemainAfterExit=yes PIDFile=/run/lcdproc.pid #ExecStart=/usr/bin/lcdproc -c /etc/lcdproc/lcdproc.conf ExecStart=/usr/bin/lcdproc -c /etc/lcdproc.conf ControlGroup=cpu:/ [Install] WantedBy=multi-user.target ----------------- service LCDd start service lcdproc start and lcd work :)
Keywords: (none) => Junior_job, PATCHCC: (none) => doktor5000Hardware: x86_64 => All
CC: (none) => alien
I don't really know why i'm CC'ed... but, it looks like a good start, but i hardly think that using systemd vs initscripts is the real bug. well, maybe it should also be started from udev or something @Gabor: hey, are you interested in joining packager's team? and maintaining LCDd?
CC: (none) => mageia
(In reply to comment #1) > I don't really know why i'm CC'ed... as you know I cc people which committed on the rpms (with some exception) http://svnweb.mageia.org/packages/updates/2/lcdproc/current/SPECS/lcdproc.spec?view=log
hmm, i had forgotten i had committed...
So udev shouldn't actually "start" daemons itself. udev these days has a policy that it kills off any still running processes after it's done processing it's rules (they are considered to be wayward helper binaries). It can of course trigger a service start via systemd, something that was not possible in the pre-systemd days. This gives a much cleaner execution environment overall. But as this is Mga2, I'll keep it on-topic :) So, some comments about the systemd units. 1. It's likely not appropriate to use the ControlGroup= variable, especially when setting it to cpu:/ which has specific semantics and meaning. The cpu:/ cgroup is designed to allow service wide CPU time control - e.g. if you have two services you can use the cpu:/ control group to give apache (which may spawn 100 cgi handlers) the same amount of CPU time overall as mysql (which may only have a couple processes). This is very different to "nicing" which operates at a per-process level. If you are interested in this, have a read of: http://0pointer.de/blog/projects/resources.html 2. I'm not sure of the relationship between LCDd and lcdproc. In the initscript they were run together, but it does seem more sensible to run them separately. If lcdproc needs LCDd, then I would suggest adding a "Requires=LCDd.service" and a "After=LCDd.service" to lcdproc.service. Will will mean if you enable the lcdproc.service, even when LCDd.service is disabled, it will be automatically started (as it's "Required") and systemd will ensure LCDd.service is fully started (normally governed by a PIDFile that is only written when the daemon has finished loading) tho' that appears not to be possible here) before it will try to start lcdproc.service. So the systemd units still need a bit of work, but it's certainly progress! However, I don't think the fact that there is a systemd unit here has actually changed things with regards to it working. The sysvinit script *should* work as well as the systemd units. I think the underlying problem is something else. The operation not permitted bit is key I think, but I'm not clued up on what operation it will actually be doing!
Hi, thanks for reporting this bug. Assigned to the package maintainer.
Keywords: (none) => TriagedCC: (none) => stormiAssignee: bugsquad => alien
If this is only mga2, i'm not likely to fix it. is this reproducable in mga3/cauldron?
This message is a reminder that Mageia 2 is nearing its end of life. Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- The Mageia Bugsquad
Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- The Mageia Bugsquad
Status: NEW => RESOLVEDResolution: (none) => OLD