Re: [systemd-devel] [PATCH] sysv-generator: only allow regular files in enumerate_sysv()
On Wed, Jan 14, 2015 at 02:51:41AM -0300, Cristian Rodríguez wrote:
> Otherwise, if the directory contains other directories we fail
> at fopen in load_sysv() with EISDIR.
> ---
> src/sysv-generator/sysv-generator.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/sysv-generator/sysv-generator.c
> b/src/sysv-generator/sysv-generator.c
> index 2f24ef2..e15a16b 100644
> --- a/src/sysv-generator/sysv-generator.c
> +++ b/src/sysv-generator/sysv-generator.c
> @@ -727,8 +727,10 @@ static int enumerate_sysv(LookupPaths lp, Hashmap
> *all_services) {
> _cleanup_free_ char *fpath = NULL, *name = NULL;
> int r;
>
> -if (hidden_file(de->d_name))
> -continue;
> +dirent_ensure_type(d, de);
> +
> +if (!dirent_is_file(de))
> +continue;
>
Applied.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build: export symbols to integrate mainloops
On Wed, Jan 21, 2015 at 10:59:45PM -0200, Lucas De Marchi wrote: > --- > src/libsystemd/libsystemd.sym.m4 | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/src/libsystemd/libsystemd.sym.m4 > b/src/libsystemd/libsystemd.sym.m4 > index 19a49f4..41418b9 100644 > --- a/src/libsystemd/libsystemd.sym.m4 > +++ b/src/libsystemd/libsystemd.sym.m4 > @@ -382,6 +382,9 @@ global: > sd_event_add_child; > sd_event_add_defer; > sd_event_add_exit; > +sd_event_wait; > +sd_event_prepare; > +sd_event_dispatch; > sd_event_run; > sd_event_loop; > sd_event_exit; Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-vconsole-setup fails very slowly
On Wed, Jan 21, 2015 at 07:15:12PM -0800, Andy Lutomirski wrote: > Hi all- > > When running virtme (a simple vm gadget) on Fedora 21, the slowest > part of bootup by far appears to be systemd-vconsole-setup: > > # time /usr/lib/systemd/systemd-vconsole-setup > putfont: PIO_FONT trying ... > ... > setfont: putfont: 512,8x16: failed: -1 > putfont: PIO_FONT: Invalid argument > /usr/bin/setfont failed with error code 71. > > real0m5.361s > user0m0.079s > sys0m0.093s > > I have no idea what it's trying to do, why it thinks it should work, > or why it doesn't work, but can it be updated to fail quickly. The VM > in question has no graphics: Might be a kernel bug. Can you run in under strace -ttt and see what pops up? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-vconsole-setup fails very slowly
Hi all- When running virtme (a simple vm gadget) on Fedora 21, the slowest part of bootup by far appears to be systemd-vconsole-setup: # time /usr/lib/systemd/systemd-vconsole-setup putfont: PIO_FONT trying ... ... setfont: putfont: 512,8x16: failed: -1 putfont: PIO_FONT: Invalid argument /usr/bin/setfont failed with error code 71. real0m5.361s user0m0.079s sys0m0.093s I have no idea what it's trying to do, why it thinks it should work, or why it doesn't work, but can it be updated to fail quickly. The VM in question has no graphics: # lspci 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:02.0 Unclassified device [0002]: Red Hat, Inc Virtio filesystem 00:03.0 System peripheral: Intel Corporation 6300ESB Watchdog Timer To reproduce on Fedora 21: $ sudo dnf install virtme $ virtme-run --installed-kernel Then twiddle your thumbs for ~6.3 seconds instead of the ~1.3 seconds of thumb twiddling that would be required AFAICT without this issue. Thanks, Andy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] build: export symbols to integrate mainloops
--- src/libsystemd/libsystemd.sym.m4 | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/libsystemd/libsystemd.sym.m4 b/src/libsystemd/libsystemd.sym.m4 index 19a49f4..41418b9 100644 --- a/src/libsystemd/libsystemd.sym.m4 +++ b/src/libsystemd/libsystemd.sym.m4 @@ -382,6 +382,9 @@ global: sd_event_add_child; sd_event_add_defer; sd_event_add_exit; +sd_event_wait; +sd_event_prepare; +sd_event_dispatch; sd_event_run; sd_event_loop; sd_event_exit; -- 2.2.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd link file not setting MTU
On Wed, Jan 21, 2015 at 8:50 PM, Ian Pilcher wrote: > I found my problem: > > [root@localhost ~]# cat /usr/lib/systemd/network/99-default.link > [Link] > NamePolicy=kernel database onboard slot path > MACAddressPolicy=persistent > > It looks like this matches any interface and prevents any other settings > from being applied. > > Renaming my file to /etc/systemd/network/98-eth0.link makes it work. Great! That would explain it :) Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Replace Provides: symlinks with real units
On 01/21/2015 08:00 PM, Michael Biebl wrote: 2015-01-21 20:56 GMT+01:00 "Jóhann B. Guðmundsson" : On 01/21/2015 03:43 PM, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jan 21, 2015 at 11:08:44AM +0100, Martin Pitt wrote: So I expect if it gets dropped upstream, a lot of distros (and all the major ones) will have to bring that back; it's IMHO better to just maintain it upstream by the distro maintainers. Exactly. Dropping it would be just busy work for everyone. General purpose distributions need to carry it for the forseeable future. That argument does not hold water since there are systemd and core/baseOS consumers that want the other side of that coin and have to patch out all the legacy stuff. That's non-sense. The sysv-generator is a separate component which can be disabled via a configure switch. No need to patch anything out. Let me re-phrase that "configure it" out... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Replace Provides: symlinks with real units
2015-01-21 20:56 GMT+01:00 "Jóhann B. Guðmundsson" : > > On 01/21/2015 03:43 PM, Zbigniew Jędrzejewski-Szmek wrote: >> >> On Wed, Jan 21, 2015 at 11:08:44AM +0100, Martin Pitt wrote: >>> >>> >So I expect if it gets dropped upstream, a lot of distros (and all the >>> >major ones) will have to bring that back; it's IMHO better to just >>> >maintain it upstream by the distro maintainers. >> >> Exactly. Dropping it would be just busy work for everyone. General >> purpose distributions need to carry it for the forseeable future. > > > That argument does not hold water since there are systemd and core/baseOS > consumers that want the other side of that coin and have to patch out all > the legacy stuff. That's non-sense. The sysv-generator is a separate component which can be disabled via a configure switch. No need to patch anything out. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Replace Provides: symlinks with real units
On 01/21/2015 03:43 PM, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jan 21, 2015 at 11:08:44AM +0100, Martin Pitt wrote: >So I expect if it gets dropped upstream, a lot of distros (and all the >major ones) will have to bring that back; it's IMHO better to just >maintain it upstream by the distro maintainers. Exactly. Dropping it would be just busy work for everyone. General purpose distributions need to carry it for the forseeable future. That argument does not hold water since there are systemd and core/baseOS consumers that want the other side of that coin and have to patch out all the legacy stuff. Arguably upstream should be leading everybody into the future not dwelling on the past and having to maintain it in the process. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd link file not setting MTU
I found my problem: [root@localhost ~]# cat /usr/lib/systemd/network/99-default.link [Link] NamePolicy=kernel database onboard slot path MACAddressPolicy=persistent It looks like this matches any interface and prevents any other settings from being applied. Renaming my file to /etc/systemd/network/98-eth0.link makes it work. -- Ian Pilcher arequip...@gmail.com "I grew up before Mark Zuckerberg invented friendship" ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] initial sysv-generator test suite
Hey Simon, Simon McVittie [2015-01-21 14:31 +]: > systemd currently has > > AM_INIT_AUTOMAKE([foreign 1.11 -Wall -Wno-portability silent-rules > tar-pax no-dist-gzip dist-xz subdir-objects]) > > but Automake 1.11 and 1.12 use the old serial test harness by default. > That doesn't understand the "log compiler" concept. > > You'll need to either depend on 1.13 (change the 1.11 to 1.13), or add > the "parallel-tests" option. Thanks for pointing out! Fixed in http://cgit.freedesktop.org/systemd/systemd/commit/?id=91ca5bf0 Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Replace Provides: symlinks with real units
Hey Zbigniew,
Zbigniew Jędrzejewski-Szmek [2015-01-21 16:36 +0100]:
> On Wed, Jan 21, 2015 at 10:46:03AM +0100, Martin Pitt wrote:
> > Keeping track of which alias symlinks we actually want is error prone, and
> > restricting the creation of services for enabled init.d scripts would reduce
> > the utility of the generator (for manual starting disabled init.d scripts)
> > as
> > well as not cover the second case. So if we encounter an existing symlink,
> > just
> > remove it before writing a real unit.
> Looks fine. Although the code is clearer than the description :)
Heh. I removed the above rationale why it isn't done in a different
way, as it might be indeed overcomplicating the commit log.
> > +log_debug("loading SysV script %s", s->path);
> Capital "L"?
Fixed.
> Looks fine from my POV.
Thanks for the review! Pushed.
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Replace Provides: symlinks with real units
On Wed, Jan 21, 2015 at 11:08:44AM +0100, Martin Pitt wrote: > So I expect if it gets dropped upstream, a lot of distros (and all the > major ones) will have to bring that back; it's IMHO better to just > maintain it upstream by the distro maintainers. Exactly. Dropping it would be just busy work for everyone. General purpose distributions need to carry it for the forseeable future. In the same vein, altough I don't think we should implement significant new features, we should update the sysv script compatibility as needed to keep it useful. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Replace Provides: symlinks with real units
On Wed, Jan 21, 2015 at 10:46:03AM +0100, Martin Pitt wrote:
> Keeping track of which alias symlinks we actually want is error prone, and
> restricting the creation of services for enabled init.d scripts would reduce
> the utility of the generator (for manual starting disabled init.d scripts) as
> well as not cover the second case. So if we encounter an existing symlink,
> just
> remove it before writing a real unit.
Looks fine. Although the code is clearer than the description :)
> Note that two init.d scripts "foo" and "bar" which both provide the same name
> "common" already work. The first processed init script wins and creates the
> "common.service" symlink, and the second just fails to create the symlink
> again. Thus create an additional test case for this to ensure that it keeps
> working sensibly.
>
> https://bugs.debian.org/775404
> ---
> src/sysv-generator/sysv-generator.c | 12
> test/sysv-generator-test.py | 38
> +
> 2 files changed, 50 insertions(+)
>
> diff --git a/src/sysv-generator/sysv-generator.c
> b/src/sysv-generator/sysv-generator.c
> index a47b072..fd3ee20 100644
> --- a/src/sysv-generator/sysv-generator.c
> +++ b/src/sysv-generator/sysv-generator.c
> @@ -147,6 +147,7 @@ static int generate_unit_file(SysvStub *s) {
> _cleanup_free_ char *wants = NULL;
> _cleanup_free_ char *conflicts = NULL;
> int r;
> +struct stat st;
>
> before = strv_join(s->before, " ");
> if (!before)
> @@ -168,6 +169,14 @@ static int generate_unit_file(SysvStub *s) {
> if (!unit)
> return log_oom();
>
> +/* We might already have a symlink with the same name from a
> Provides:,
> + * or from backup files like /etc/init.d/foo.bak. Real scripts
> always win,
> + * so remove an existing link */
> +if (lstat(unit, &st) == 0 && S_ISLNK(st.st_mode)) {
> +log_warning("Overwriting existing symlink %s with real
> service", unit);
> +unlink(unit);
> +}
> +
> f = fopen(unit, "wxe");
> if (!f)
> return log_error_errno(errno, "Failed to create unit file
> %s: %m", unit);
> @@ -343,6 +352,8 @@ static int load_sysv(SysvStub *s) {
> if (!f)
> return errno == ENOENT ? 0 : -errno;
>
> +log_debug("loading SysV script %s", s->path);
Capital "L"?
> +
> while (!feof(f)) {
> char l[LINE_MAX], *t;
>
> @@ -492,6 +503,7 @@ static int load_sysv(SysvStub *s) {
> continue;
>
> if (unit_name_to_type(m) ==
> UNIT_SERVICE) {
> +log_debug("Adding Provides:
> alias '%s' for '%s'", m, s->name);
> r = add_alias(s->name, m);
> } else {
> /* NB: SysV targets
> diff --git a/test/sysv-generator-test.py b/test/sysv-generator-test.py
> index a3daa9f..63a10ec 100644
> --- a/test/sysv-generator-test.py
> +++ b/test/sysv-generator-test.py
> @@ -271,6 +271,25 @@ class SysvGeneratorTest(unittest.TestCase):
> self.assertEqual(os.readlink(os.path.join(self.out_dir, f)),
> 'foo.service')
>
> +def test_same_provides_in_multiple_scripts(self):
> +'''multiple init.d scripts provide the same name'''
> +
> +self.add_sysv('foo', {'Provides': 'foo common'}, enable=True, prio=1)
> +self.add_sysv('bar', {'Provides': 'bar common'}, enable=True, prio=2)
> +err, results = self.run_generator()
> +self.assertEqual(sorted(results), ['bar.service', 'foo.service'])
> +# should create symlink for the alternative name for either unit
> +self.assertIn(os.readlink(os.path.join(self.out_dir,
> 'common.service')),
> + ['foo.service', 'bar.service'])
> +
> +def test_provide_other_script(self):
> +'''init.d scripts provides the name of another init.d script'''
> +
> +self.add_sysv('foo', {'Provides': 'foo bar'}, enable=True)
> +self.add_sysv('bar', {'Provides': 'bar'}, enable=True)
> +err, results = self.run_generator()
> +self.assertEqual(sorted(results), ['bar.service', 'foo.service'])
> +
> def test_nonexecutable_script(self):
> '''ignores non-executable init.d script'''
>
> @@ -313,6 +332,25 @@ class SysvGeneratorTest(unittest.TestCase):
> self.assertEqual(os.readlink(os.path.join(self.out_dir,
> 'bar.service')),
> 'foo.service')
>
> +def test_backup_file(self):
> +'''init.d script with backup file'''
> +
> +script = self.add_sysv('foo', {}, enable=True)
> +# backup files (not enabled in rcN.d/)
> +shutil.copy(script, script + '.bak
Re: [systemd-devel] [PATCH] initial sysv-generator test suite
On 21 January 2015 at 14:31, Simon McVittie wrote: > On 20/01/15 20:33, Martin Pitt wrote: >> Dimitri John Ledkov [2015-01-20 18:23 +]: >>> With parallel test harness in automake (everyone should have it by >>> now) >> >> Yay, thanks for pointing this out! That makes the whole thing indeed >> much friendlier. > > systemd currently has > > AM_INIT_AUTOMAKE([foreign 1.11 -Wall -Wno-portability silent-rules > tar-pax no-dist-gzip dist-xz subdir-objects]) > > but Automake 1.11 and 1.12 use the old serial test harness by default. > That doesn't understand the "log compiler" concept. > > You'll need to either depend on 1.13 (change the 1.11 to 1.13), or add > the "parallel-tests" option. Although automake 1.13 is two years old, imho it's best to specify "parallel-tests" for now. No need to jump higher. -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] initial sysv-generator test suite
On 20/01/15 20:33, Martin Pitt wrote: > Dimitri John Ledkov [2015-01-20 18:23 +]: >> With parallel test harness in automake (everyone should have it by >> now) > > Yay, thanks for pointing this out! That makes the whole thing indeed > much friendlier. systemd currently has AM_INIT_AUTOMAKE([foreign 1.11 -Wall -Wno-portability silent-rules tar-pax no-dist-gzip dist-xz subdir-objects]) but Automake 1.11 and 1.12 use the old serial test harness by default. That doesn't understand the "log compiler" concept. You'll need to either depend on 1.13 (change the 1.11 to 1.13), or add the "parallel-tests" option. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] sysv-generator: Handle .sh suffixes when translating Provides:
Martin Pitt [2015-01-21 9:49 +0100]: > One more adjustment to master, considering a recent change in the > sysv-generator tests. Thomas and Michael both reviewed this patch, it's quite straightforward, and it fixes quite a severe regression, so I pushed it now. I don't want to push the other one without some review, though, as it's much less clear what the right solution is. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Handle .sh suffixes when translating Provides:
2015-01-20 17:44 GMT+01:00 Martin Pitt : > Hey all, > > the recent fix for sysv-generator's Provides: handling [1] caused, or > rather uncovered, another bug which now creates symlinks to itself > "foo.service -> foo.service" for any /etc/init.d/foo.sh. > > The generator would output an error message like > > Failed to create unit file /foo.service: File exists > > instead of creating the actual foo.service file. I. e. this completely > breaks translating init scripts with .sh. > > Fix with corresponding test case attached. This is a test case for the > test suite I sent in my previous mail; that might still need some > masssaging, so if you are ok with this fix, I'll commit that without > the test case, and add the test case to the suite separately. > I think I'd drop the log_debug in sysv_translate_facility(), otherwise looks good to me. Thanks for fixing that! Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Second (erroneous) check of rootfs?
On 11.01.2015 12:57, Andrei Borzenkov wrote: > Does it using systemd *inside* of initrd? From upstream dracut: > > if ! dracut_module_included "systemd"; then > inst_hook cmdline 95 "$moddir/parse-block.sh" > inst_hook pre-udev 30 "$moddir/block-genrules.sh" > inst_hook mount 99 "$moddir/mount-root.sh" > ^ here it does it > fi In Fedora systemd is used in the initramfs. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [logind] retroactive lid close handle upon vt switch
Hello, consider two vt sessions vt1, vt2. On vt1 handle-lid-switch is inhibited. Now the lid is closed and than a vt switch takes place (e.g. "sleep 10 && loginctl activate vt2"). Now the system suspends. I guess this is because the new active session has no inhibitor lock on handle-lid-switch and therefor retroactively reacts to the closed lid. Is this intentional or could it be changed? Background: There are screen locker, which use the display managers login screen for unlocking the session; e.g. light-locker + lightdm. Locking a session involves a vt switch to display the authentication screen. If such a locker gets started while the lid is closed, the system suspends, even if the original session inhibited the handle-lid-switch. Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Replace Provides: symlinks with real units
Hey Jóhann, "Jóhann B. Guðmundsson" [2015-01-21 9:59 +]: > Seems like a corner case as administrator should fix himself by not backing > up files in the /etc/init.d directory so arguably this broken behaviour is > expect. With SysV init this isn't "broken" at all. As long as you don't actually enable the backup files in rcN.d/, this is perfectly valid. The effect is that systems with such backup files work fine under SysV init and even under systemd up to 218, but will fail to boot under systemd 219 onwards (i. e. with current master). I call this a regression. > That said at one point or another we need to drop legacy sysv > initscript support and have downstream the generator themselves if > they intend on supporting legacy sysv initscripts. If upstream wants to drop it at some point that's their prerogative of course. I'd advise against it though, as LSB compliant systems need to support SysV init scripts, it's still the lowest common denoniator, and tons of third-party software still ship with init.d scripts. I. e. it's not enough to port the distro packages. So I expect if it gets dropped upstream, a lot of distros (and all the major ones) will have to bring that back; it's IMHO better to just maintain it upstream by the distro maintainers. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] _systemctl.in: Do not interpret escape sequences in _filter_units_by_property
Hey Wieland,
Wieland Hoffmann [2015-01-17 2:10 +0100]:
> This makes all functions that rely on _f_u_b_p (like
> _systemctl_{stop,kill,try_restart}) work with unit names that contain
> backslash escaped sequences (like automount units with spaces that are
> escaped to "\x20").
Confirmed to work. Pushed with a slight changelog tweak:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=e37b56c7
Thanks!
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Replace Provides: symlinks with real units
On 01/21/2015 09:46 AM, Martin Pitt wrote: while working on the sysv generator, some more cases came up where the recently introduced "Provides:" symlink handling [1] causes trouble [2]. As soon as you have backup files like /etc/init.d/foo.bak, you'll get a "foo.service -> foo.bak.service" link which prevents the creation of a real foo.service unit Seems like a corner case as administrator should fix himself by not backing up files in the /etc/init.d directory so arguably this broken behaviour is expect. That said at one point or another we need to drop legacy sysv initscript support and have downstream the generator themselves if they intend on supporting legacy sysv initscripts. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] sysv-generator: Handle .sh suffixes when translating Provides:
Dimitri John Ledkov [2015-01-21 9:47 +]: > I've also been bitten by generators defaulting to "do not override > file with same name" when writing out actual unit with contents. > There should not be any masked units inside generator/ generator.late/ > directories and thus if a file already exists and is empty / broken > symlink it should be force overwritten. Indeed; that's a bit ugly, but IMHO still better than the current behaviour which is just dangerously broken. I sent a patch a few minutes ago (http://lists.freedesktop.org/archives/systemd-devel/2015-January/027249.html) Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] sysv-generator: Handle .sh suffixes when translating Provides:
On 21 January 2015 at 07:27, Martin Pitt wrote: > Martin Pitt [2015-01-20 17:44 +0100]: >> the recent fix for sysv-generator's Provides: handling [1] caused, or >> rather uncovered, another bug which now creates symlinks to itself >> "foo.service -> foo.service" for any /etc/init.d/foo.sh. >> >> The generator would output an error message like >> >> Failed to create unit file /foo.service: File exists >> >> instead of creating the actual foo.service file. I. e. this completely >> breaks translating init scripts with .sh. > > Reworked the patch to apply to current master (where the > sysv-generator test suite now landed), drop the log_debug() leftover, > and clean up the tests. > > Note that Michael points out some more problems with the Provides: > alias handling ([1], [2]); I'll work on those next, but this is > already a self-contained and urgent fix, so I think it's good to push. > I've also been bitten by generators defaulting to "do not override file with same name" when writing out actual unit with contents. There should not be any masked units inside generator/ generator.late/ directories and thus if a file already exists and is empty / broken symlink it should be force overwritten. no? -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] sysv-generator: Replace Provides: symlinks with real units
Hello all,
while working on the sysv generator, some more cases came up where the
recently introduced "Provides:" symlink handling [1] causes trouble
[2]. As soon as you have backup files like /etc/init.d/foo.bak, you'll
get a "foo.service -> foo.bak.service" link which prevents the
creation of a real foo.service unit. A similar case can also happen if
one init.d script Provides: the name of another init.d script
(arguably this is at least questionable, but it might happen in
practice -- e. g. /etc/init.d/mariad might very well "Provides: mysql"
as it's kind of a drop-in replacement).
I wrote some more tests which reproduce these failures, and a proposed
patch. It's not exactly nice due to the TOCTOU (which shouldn't cause
any practical problem though, it's just a bit unclean), but I can't
think of a better solution which covers all corner cases.
Details are in the git commit message. Note that this currently adds
two log_debug() statements, so that you can better see what's going on
(and wrong) in the output for test failures. If you don't want to keep
them, I'm fine with dropping them again of course.
Opinions? (Especially from Thomas?)
Thanks,
Martin
[1] http://cgit.freedesktop.org/systemd/systemd/commit/?id=b7e7184634d5
[2] https://bugs.debian.org/775404
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From cb5c1727a62df698fb69bb2ab1fbd634f2283a0b Mon Sep 17 00:00:00 2001
From: Martin Pitt
Date: Wed, 21 Jan 2015 10:25:14 +0100
Subject: [PATCH 2/2] sysv-generator: Replace Provides: symlinks with real
units
Since commit b7e7184 the SysV generator creates symlinks for all "Provides:" in
the LSB header. However, this is too greedy; there are cases where the
creation of a unit .service file fails because of an already existing
symlink with the same name:
- Backup files such as /etc/init.d/foo.bak still have "Provides: foo", and
thus get a foo.service -> foo.bak.service link. foo.bak would not be enabled
in rcN.d/, but we (deliberately) create units for all executables in init.d/
so that a manual "systemctl start" works. If foo.bak is processed before,
the symlink already exists.
- init.d/bar has "Provides: foo", while there also is a real init.d/foo. The
former would create a link foo.service -> bar.service, while the latter
would fail to create the real foo.service.
Keeping track of which alias symlinks we actually want is error prone, and
restricting the creation of services for enabled init.d scripts would reduce
the utility of the generator (for manual starting disabled init.d scripts) as
well as not cover the second case. So if we encounter an existing symlink, just
remove it before writing a real unit.
Note that two init.d scripts "foo" and "bar" which both provide the same name
"common" already work. The first processed init script wins and creates the
"common.service" symlink, and the second just fails to create the symlink
again. Thus create an additional test case for this to ensure that it keeps
working sensibly.
https://bugs.debian.org/775404
---
src/sysv-generator/sysv-generator.c | 12
test/sysv-generator-test.py | 38 +
2 files changed, 50 insertions(+)
diff --git a/src/sysv-generator/sysv-generator.c b/src/sysv-generator/sysv-generator.c
index a47b072..fd3ee20 100644
--- a/src/sysv-generator/sysv-generator.c
+++ b/src/sysv-generator/sysv-generator.c
@@ -147,6 +147,7 @@ static int generate_unit_file(SysvStub *s) {
_cleanup_free_ char *wants = NULL;
_cleanup_free_ char *conflicts = NULL;
int r;
+struct stat st;
before = strv_join(s->before, " ");
if (!before)
@@ -168,6 +169,14 @@ static int generate_unit_file(SysvStub *s) {
if (!unit)
return log_oom();
+/* We might already have a symlink with the same name from a Provides:,
+ * or from backup files like /etc/init.d/foo.bak. Real scripts always win,
+ * so remove an existing link */
+if (lstat(unit, &st) == 0 && S_ISLNK(st.st_mode)) {
+log_warning("Overwriting existing symlink %s with real service", unit);
+unlink(unit);
+}
+
f = fopen(unit, "wxe");
if (!f)
return log_error_errno(errno, "Failed to create unit file %s: %m", unit);
@@ -343,6 +352,8 @@ static int load_sysv(SysvStub *s) {
if (!f)
return errno == ENOENT ? 0 : -errno;
+log_debug("loading SysV script %s", s->path);
+
while (!feof(f)) {
char l[LINE_MAX], *t;
@@ -492,6 +503,7 @@ static int load_sysv(SysvStub *s) {
continue;
if (unit_name_to_type(m) == UNIT_SERVICE) {
+log_debug("Adding Provides: alias '%s' for '%s'", m, s->
[systemd-devel] [PATCH v3] sysv-generator: Handle .sh suffixes when translating Provides:
Martin Pitt [2015-01-21 8:27 +0100]:
> Reworked the patch to apply to current master (where the
> sysv-generator test suite now landed), drop the log_debug() leftover,
> and clean up the tests.
One more adjustment to master, considering a recent change in the
sysv-generator tests.
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From 6344a9d8f1af9d9e8d8e9313e742c82be150f215 Mon Sep 17 00:00:00 2001
From: Martin Pitt
Date: Tue, 20 Jan 2015 16:41:31 +0100
Subject: [PATCH] sysv-generator: Handle .sh suffixes when translating
Provides:
When deciding whether the provided name equals the file name in
sysv_translate_facility(), also consider them equal if the file name has a
".sh" suffix.
This was uncovered by commit b7e7184 which then created a symlink
".service" to itself for ".sh" suffixed init.d scripts.
For additional robustness, refuse to create symlinks to itself in add_alias().
Add test case which reproduces the bug.
---
src/sysv-generator/sysv-generator.c | 15 ++-
test/sysv-generator-test.py | 36
2 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/src/sysv-generator/sysv-generator.c b/src/sysv-generator/sysv-generator.c
index 4774981..a47b072 100644
--- a/src/sysv-generator/sysv-generator.c
+++ b/src/sysv-generator/sysv-generator.c
@@ -119,6 +119,11 @@ static int add_alias(const char *service, const char *alias) {
assert(service);
assert(alias);
+if (streq(service, alias)) {
+log_error("Ignoring creation of an alias %s for itself", service);
+return 0;
+}
+
link = strjoin(arg_dest, "/", alias, NULL);
if (!link)
return log_oom();
@@ -263,6 +268,7 @@ static int sysv_translate_facility(const char *name, const char *filename, char
unsigned i;
char *r;
const char *n;
+_cleanup_free_ char *filename_no_sh = NULL;
assert(name);
assert(_r);
@@ -284,6 +290,13 @@ static int sysv_translate_facility(const char *name, const char *filename, char
goto finish;
}
+/* strip ".sh" suffix from file name for comparison */
+filename_no_sh = strdup(filename);
+if (!filename_no_sh)
+return -ENOMEM;
+if (endswith(filename, ".sh"))
+filename_no_sh[strlen(filename)-3] = '\0';
+
/* If we don't know this name, fallback heuristics to figure
* out whether something is a target or a service alias. */
@@ -293,7 +306,7 @@ static int sysv_translate_facility(const char *name, const char *filename, char
/* Facilities starting with $ are most likely targets */
r = unit_name_build(n, NULL, ".target");
-} else if (filename && streq(name, filename))
+} else if (filename && streq(name, filename_no_sh))
/* Names equaling the file name of the services are redundant */
return 0;
else
diff --git a/test/sysv-generator-test.py b/test/sysv-generator-test.py
index 492e99d..7aaa088 100644
--- a/test/sysv-generator-test.py
+++ b/test/sysv-generator-test.py
@@ -278,6 +278,42 @@ class SysvGeneratorTest(unittest.TestCase):
err, results = self.run_generator()
self.assertEqual(results, {})
+def test_sh_suffix(self):
+'''init.d script with .sh suffix'''
+
+self.add_sysv('foo.sh', {}, enable=True)
+err, results = self.run_generator()
+s = results['foo.service']
+
+self.assertEqual(s.sections(), ['Unit', 'Service'])
+# should not have a .sh
+self.assertEqual(s.get('Unit', 'Description'), 'LSB: test foo service')
+
+# calls correct script with .sh
+init_script = os.path.join(self.init_d_dir, 'foo.sh')
+self.assertEqual(s.get('Service', 'ExecStart'),
+ '%s start' % init_script)
+self.assertEqual(s.get('Service', 'ExecStop'),
+ '%s stop' % init_script)
+
+self.assert_enabled('foo.service', [2, 3, 4, 5])
+
+def test_sh_suffix_with_provides(self):
+'''init.d script with .sh suffix and Provides:'''
+
+self.add_sysv('foo.sh', {'Provides': 'foo bar'})
+err, results = self.run_generator()
+# ensure we don't try to create a symlink to itself
+self.assertNotIn(err, 'itself')
+self.assertEqual(list(results), ['foo.service'])
+self.assertEqual(results['foo.service'].get('Unit', 'Description'),
+ 'LSB: test foo service')
+
+# should create symlink for the alternative name
+self.assertEqual(os.readlink(os.path.join(self.out_dir, 'bar.service')),
+ 'foo.service')
+
+
if __name__ == '__main__':
unittest.main(testRunner=unittest.TextTestRunner(stream=sys.stdou
Re: [systemd-devel] networkd link file not setting MTU
On Wed, Jan 21, 2015 at 2:53 AM, Cameron Norman wrote: > On Tue, Jan 20, 2015 at 4:40 PM, Tom Gundersen wrote: >> Hi Ian, >> >> Did you try to reboot? Note that .link files are applied by udev (so >> usually during early boot). You can override their settings from >> .network files in some cases (at least with current git you can). >> > > Out of curiosity and for future reference, is there any way to get > udev to apply the link files without rebooting? E.g. possibly with a > udevadm trigger command of some sort. # udevadm trigger --action=add /sys/class/net/eth0 Not really recommended though, these things are really _not_ meant to be changed at run-time, but rather provide a saner (and configurable) default when the devices first appear (and before libudev annonces them to the rest of the system) than what the kernel does. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
