The default /etc/conf.d/ntp-client reads in part: NTPCLIENT_OPTS="-s -b -u \ 0.gentoo.pool.ntp.org 1.gentoo.pool.ntp.org \ 2.gentoo.pool.ntp.org 3.gentoo.pool.ntp.org" When attempting to start ntp-client.service, it fails, and the journal gets messages reading in part Ignoring invalid environment no servers can be used, exiting Modifying the file to have the variable set on one line makes it work: NTPCLIENT_OPTS="-s -b -u 0.gentoo.pool.ntp.org 1.gentoo.pool.ntp.org 2.gentoo.pool.ntp.org 3.gentoo.pool.ntp.org" Reproducible: Always Steps to Reproduce: 1. Install ntp-4.2.6_p5-r3 (only version with systemd support) 2. Install and use systemd 3. systemctl start ntp-client Actual Results: Time not set, following message appears in journalctl: Aug 18 11:47:52 mangobot systemd[1]: Starting Set time via NTP... Aug 18 11:47:52 mangobot systemd[1]: Ignoring invalid environment 'NTPCLIENT_OPTS=-s -b -u 0.gentoo.pool.ntp.org 1.gentoo.pool.ntp.org 2.gentoo.pool.ntp.org 3.gentoo.pool.ntp.org': /etc/conf.d/ntp-client Aug 18 11:47:52 mangobot ntpdate[31628]: 18 Aug 11:47:52 ntpdate[31628]: no servers can be used, exiting Aug 18 11:47:52 mangobot systemd[1]: ntp-client.service: main process exited, code=exited, status=1/FAILURE Aug 18 11:47:52 mangobot systemd[1]: Failed to start Set time via NTP. Expected Results: Time set, no error The systemd.exec (http://0pointer.de/public/systemd-man/systemd.exec.html) manpage describes the format, and it seems like the original should conform, but it did not work for me when I actually tried.
It's odd but replacing: NTPCLIENT_OPTS="-s -b -u \ 0.gentoo.pool.ntp.org 1.gentoo.pool.ntp.org \ 2.gentoo.pool.ntp.org 3.gentoo.pool.ntp.org" by: NTPCLIENT_OPTS="-s -b -u 0.gentoo.pool.ntp.org 1.gentoo.pool.ntp.org 2.gentoo.pool.ntp.org 3.gentoo.pool.ntp.org" seems to solve the issue.
CC'ing systemd in case there are some oddities with the unit files reading multiline env vars.
I suspect this simply isn't supported. Much like EnvironmentFiles are strongly discouraged and tying .service files to conf.d is rather short-sighted. We are planning to discuss the issues with EnvironmentFiles in the team soon and we'll then decide how to proceed.
Hi, there was a similar problem with sys-devel/distcc after adding systemd support, see https://bugs.gentoo.org/show_bug.cgi?id=470848#c0 => Multilines are not supported (POSIX?). Not sure if NTPCLIENT_OPTS="-s -b -u" NTPCLIENT_OPTS="${NTPCLIENT_OPTS} 0.gentoo.pool.ntp.org" NTPCLIENT_OPTS="${NTPCLIENT_OPTS} 1.gentoo.pool.ntp.org" NTPCLIENT_OPTS="${NTPCLIENT_OPTS} 2.gentoo.pool.ntp.org" NTPCLIENT_OPTS="${NTPCLIENT_OPTS} 3.gentoo.pool.ntp.org" would be a possible way to go. At least it is better maintainable like a one-liner, don't you agree?
> Not sure if > > NTPCLIENT_OPTS="-s -b -u" > NTPCLIENT_OPTS="${NTPCLIENT_OPTS} 0.gentoo.pool.ntp.org" > NTPCLIENT_OPTS="${NTPCLIENT_OPTS} 1.gentoo.pool.ntp.org" > NTPCLIENT_OPTS="${NTPCLIENT_OPTS} 2.gentoo.pool.ntp.org" > NTPCLIENT_OPTS="${NTPCLIENT_OPTS} 3.gentoo.pool.ntp.org" > > would be a possible way to go. *argh* I should read what I link: > thus you can't have something like A="${A} foo". Forget what I have written.
Something looks bogus in systemd side as, per man page, it should understand "\": EnvironmentFile= Similar to Environment= but reads the environment variables from a text file. The text file should contain new-line-separated variable assignments. Empty lines and lines starting with ; or # will be ignored, which may be used for commenting. A line ending with a backslash will be concatenated with the following one, allowing multiline variable definitions. The parser strips leading and trailing whitespace from the values of assignments, unless you use double quotes ("). The argument passed should be an absolute filename or wildcard expression, optionally prefixed with "-", which indicates that if the file does not exist it won't be read and no error or warning message is logged. This option may be specified more than once in which case all specified files are read. If the empty string is assigned to this option the list of file to read is reset, all prior assignments have no effect. The files listed with this directive will be read shortly before the process is executed. Settings from these files override settings made with Environment=. If the same variable is set twice from these files the files will be read in the order they are specified and the later setting will override the earlier setting. -> Have you tried dropping the tabs on every line? Per journalctl output looks like, effectively, it's concatenating it but with a big space (probably due tab) between them that maybe makes ntp-client don't understand it
Maybe try without the ".
I tested what proposed to play a little with the structure to test as suggested and now I'm not able to reproduce the bug. The fact that I didn't reboot between the installation of net-misc/ntp and the first launch of ntp-client.service might has trigger the bug.
sounds like a problem on the systemd issue to be clear, modifying the conf.d file in any of the proposed ways is not acceptable. conf.d files are valid POSIX shell files.
(In reply to Guillaume Poulin from comment #8) > I tested what proposed to play a little with the structure to test as > suggested and now I'm not able to reproduce the bug. The fact that I didn't > reboot between the installation of net-misc/ntp and the first launch of > ntp-client.service might has trigger the bug. What is the final conf.d file working for you?
Created attachment 357146 [details] /etc/conf.d/ntp-client
(In reply to Pacho Ramos from comment #10) > What is the final conf.d file working for you? At the end the original file worked for me. I have attached the conf.d file that I'm currently using without problem.
Will close as INVALID then (as also per man page info it should work)
Bleh, it's failing for me now :O ago 27 09:03:56 localhost systemd[1]: Ignoring invalid environment 'NTPCLIENT_OPTS=-s -b -u 0.gentoo.pool.ntp.org 1.gentoo.pool.ntp.org
That is caused by the tabs! @systemd team, is that normal? Should we report the problem to systemd upstream?
(In reply to Pacho Ramos from comment #15) > That is caused by the tabs! @systemd team, is that normal? Should we report > the problem to systemd upstream? I'd say report. Let's see what they think. Other than that, following my earlier mail I encourage you to replace the conf.d with systemd/system/ntpd.service.d/gentoo.conf :P.
(In reply to Michał Górny from comment #16) > (In reply to Pacho Ramos from comment #15) > > That is caused by the tabs! @systemd team, is that normal? Should we report > > the problem to systemd upstream? > > I'd say report. Let's see what they think. > https://bugs.freedesktop.org/show_bug.cgi?id=68592 > Other than that, following my earlier mail I encourage you to replace the > conf.d with systemd/system/ntpd.service.d/gentoo.conf :P. Even when both can be shared? (not exactly this case because of this bug report, but I am thinking in other cases that would end up having duplicated files in conf.d and /etc/systemd)
(In reply to Pacho Ramos from comment #17) > (In reply to Michał Górny from comment #16) > > (In reply to Pacho Ramos from comment #15) > > > That is caused by the tabs! @systemd team, is that normal? Should we report > > > the problem to systemd upstream? > > > > I'd say report. Let's see what they think. > > > https://bugs.freedesktop.org/show_bug.cgi?id=68592 > > > Other than that, following my earlier mail I encourage you to replace the > > conf.d with systemd/system/ntpd.service.d/gentoo.conf :P. > > Even when both can be shared? (not exactly this case because of this bug > report, but I am thinking in other cases that would end up having duplicated > files in conf.d and /etc/systemd) Yep. Think of people masking /etc/conf.d. Also, preferably you would have ExecStart= in the service.d and avoid ugly environment exporting.
(In reply to Michał Górny from comment #18) [...] > Yep. Think of people masking /etc/conf.d. > Even if I disagree with people masking that location, ok. But I think we will need to mail to gentoo-dev ML about what is the policy regarding /etc/conf.d as I think I saw some packages relying on it even for configuring the application itself (outside init.d file) :S > Also, preferably you would have ExecStart= in the service.d and avoid ugly > environment exporting. Is there any way to simply pass *additional* arguments to the executable? I mean something like this: - One line (that people shouldn't touch) with the proper path to the executable and the options that need to be used always - Another one for letting people to append options The idea is to prevent people dropping options easily by error
Well, would be the same as we have with EnvironmentFile (loading the proper one in /etc/systemd, but I was asking as I think this is the most common case for needing EnvironmentFile and maybe systemd could handle this specific case without needing it)
(In reply to Pacho Ramos from comment #20) > Well, would be the same as we have with EnvironmentFile (loading the proper > one in /etc/systemd, but I was asking as I think this is the most common > case for needing EnvironmentFile and maybe systemd could handle this > specific case without needing it) Forget it. I've just checked and you can't override ExecStart=. It tries to use both, and then bails out due to duplicate option.
(In reply to Michał Górny from comment #21) > Forget it. I've just checked and you can't override ExecStart=. It tries to > use both, and then bails out due to duplicate option. To override ExecStart, you first have to "clear" it. [Service] ExecStart= ExecStart=/usr/bin/foo a b c
This was a systemd bug that is now fixed upstream: http://cgit.freedesktop.org/systemd/systemd/commit/?id=ac4c8d6
+*systemd-206-r5 (14 Sep 2013) + + 14 Sep 2013; Pacho Ramos <pacho@gentoo.org> + +files/206-0006-allow-tabs-in-configuration-files.patch, + +files/206-0007-allow-tabs-in-configuration-files2.patch, + +systemd-206-r5.ebuild: + Allow tabs in environment files (#481554 by dolphinling) +
