| Summary: | =app-admin/metalog-3 - systemd start failure - Unknown lvalue 'Names' in section 'Unit' | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Sven E. <dark> |
| Component: | Current packages | Assignee: | Gentoo systemd Team <systemd> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Sven E.
2013-08-16 11:47:23 UTC
The unit is wrong -> needs to drop the "Units" line and add: Alias=syslog.service at the bottom (like syslog-ng does) +*metalog-3-r1 (21 Sep 2013) + + 21 Sep 2013; Pacho Ramos <pacho@gentoo.org> +files/metalog.service-r1, + +metalog-3-r1.ebuild: + Fix unit file (#481290 by Sven E.) + Unfortunately the fix only fixes the error mesage but does not resolve the actual startup issue. Even though the error mesage is gone, metalog does not get started, or it gets started and dies right away before even logging it started. Please provide the actual "status" output with latest unit file, also try to manually run the command the unit file is trying to run (In reply to Pacho Ramos from comment #4) > Please provide the actual "status" output with latest unit file, also try to > manually run the command the unit file is trying to run systemctl status metalog metalog.service - System Logger Daemon Loaded: loaded (/usr/lib64/systemd/system/metalog.service; enabled) Active: inactive (dead) systemctl status syslog metalog.service - System Logger Daemon Loaded: loaded (/usr/lib64/systemd/system/metalog.service; enabled) Active: inactive (dead) No info in the logs (/var/log/*). Running the exact command in the unitfile works, however the daemon dos not daemonize (stays attached to the terminal) and logs to the terminal (as well as the files). I tested this by sending a message manually. Does systemd handle all the detatching etc.? Or is it necessary to pass parameters within the unit file? Mentioned it in the first post, put for completeness: Running systemctl restart syslog after the system finished booting works and spawns metalog as expected The unit file is running exactly the same command as init.d script does:
/usr/sbin/metalog
The only thing that could explain that it fails at boot but not later would be that metalog needs something to be started before, but I can't see that looking to init.d:
need localmount
:/
(In reply to Pacho Ramos from comment #7) > The unit file is running exactly the same command as init.d script does: > /usr/sbin/metalog > > The only thing that could explain that it fails at boot but not later would > be that metalog needs something to be started before, but I can't see that > looking to init.d: > need localmount > > :/ I think the problem might be a systemd race, would not really be surprised. I am thinking of something like this: Loggr needs socket interface (metalog doesn't, does it?), sockets kernel module did not get loaded yet -> failure. The question is, how systemd handles service to kernel module deps etc. . Anyway, what is the appropriate way to pass parameters for systemd unit files? I could try starting metalog with debugging parameters and maybe have it run by strace or something, to see why/where it fails. You can simply edit the existing unit file in the ExeStart line for passing options and so (In reply to Pacho Ramos from comment #9) > You can simply edit the existing unit file in the ExeStart line for passing > options and so Finally got this sorted out. Systemd is just awesome *eyerolling*. Here's the story: Because of the formerly 'broken' unit file something withing systemd's managemen schemes got borked. I could neither disable metalog nor syslog (Plannd on disbaling & reenabling). Added manually a syslog.service symlink, then disabling worked. Changed unit file to not alias syslog (don't know if that really was necessary), enabled metalog et voila metalog starts. Disabled it again, changed unitfile back to include alias to syslog, enabled it, now the necesary symlinks were created properly and startup during systemstart works. Afterall it boiled down to a mising syslin in the wants directory, which for whatever reson was not created when enabling it. You really gotta love systemd for its good design and rockhard stability... P.S.: Ended up with the idea of disabling and reenabling it, since not even any other command in the unit file was run, which lead to the conclusion, that it is ignored by systemd for whatever reason, no matter what systemctl said. Congratulations for find the problem, maybe would be interesting to report this to upstream to let them know the problem... but I am unsure what summarized steps to reproduce could be provided :/ |
