Bug#890265: systemd: journalctl compiled without pattern matching support
Am 12.02.2018 um 18:02 schrieb Calum Mackay: > Package: systemd > Version: 237-2 > Severity: normal > > Dear Maintainer, > > The -g/--grep option was recently added to the man page, but: > > $ journalctl --grep=blah > Compiled without pattern matching support > > this could be a man page bug, of course, although it's a useful feature. As the message says, systemd has been compiled without pattern matching support. This is deliberate, as this would required linking against pcre2, which would basically make this library mandatory on every system. That's why I hesitated to enable that feature. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: bug 890445 is forwarded to https://github.com/systemd/systemd/issues/8216
Processing commands for cont...@bugs.debian.org: > forwarded 890445 https://github.com/systemd/systemd/issues/8216 Bug #890445 [systemd] systemd: systemctl tab-auto-completion freezes the terminal and causes 100% CPU utilization Set Bug forwarded-to-address to 'https://github.com/systemd/systemd/issues/8216'. > thanks Stopping processing here. Please contact me if you need assistance. -- 890445: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890445 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: Re: systemd: Failed to start network time synchronization
Processing control commands: > tags -1 + moreinfo Bug #890095 [systemd] systemd: Failed to start network time synchronization Added tag(s) moreinfo. -- 890095: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890095 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#890095: systemd: Failed to start network time synchronization
Control: tags -1 + moreinfo On Sun, 11 Feb 2018 03:38:51 -0200 Carlos Donizete Froes wrote: > Package: systemd > Version: 236-3 > Severity: normal > > Dear Maintainer, > > At startup, the following failures appear: > > [FAILED] Failed to start network time synchronization. > See 'systemctl status systemd-timesyncd.service' for details. > > After bootup, the command 'timedatectl' produces: > > - > coringao@debian:~$ timedatectl > Local time: dom 2018-02-11 03:03:45 -02 > Universal time: dom 2018-02-11 05:03:45 UTC > RTC time: dom 2018-02-11 05:03:46 >Time zone: America/Sao_Paulo (-02, -0200) >System clock synchronized: yes > systemd-timesyncd.service active: no > RTC in local TZ: no > - > > So I checked the statuses: > > - > coringao@debian:~$ systemctl status systemd-timesyncd > ● systemd-timesyncd.service - Network Time Synchronization >Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; > vendor preset: enabled) >Active: failed (Result: exit-code) since Sun 2018-02-11 02:15:58 -02; > 49min ago > Docs: man:systemd-timesyncd.service(8) > Process: 280 ExecStart=/lib/systemd/systemd-timesyncd (code=exited, > status=1/FAILURE) > Main PID: 280 (code=exited, status=1/FAILURE) >Status: "Shutting down..." > - > > Can anyone explain what the problem is? For that we would need a more complete log. You can get that via journalctl. That said, have you installed and enabled libnss-systemd? If not, please do so, reboot and report back if systemd-timesyncd still fails. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#890824: Container: unsets cgroup memory limit on user login
Package: systemd Version: 232-25+deb9u1 Severity: important Hi I have an issue with Systemd unsetting the memory limit for my container, whereupon programs like free and htop report having access to 8 exabyte of memory. The setup is the following: Host: Release: Debian jessie Kernel: 4.9.65-3+deb9u2~bpo8+1 (jessie backports) Container provider: libvirt 3.0.0-4~bpo8+1 (jessie backports) Systemd: 215-17+deb8u7 (jessie) cgroup hierarchy: legacy Guest: Release: Debian stretch Systemd: 232-25+deb9u1 (stretch) There are several containers running on the host, but this problem only occurs with all the Debian stretch containers. Containers running Debian jessie or older Ubuntu 12.04 aren't affected. Each container is configured to cgroup enforced memory limit in it's libvirt domain file. Example: 4194304 2097152 Steps to reproduce + observations: 1) start a container with virsh -c lxc:// container.example.com 2) virsh -c lxc:// memtune container.example.com reports a hard_limit of 2097152 3) cat "/sys/fs/cgroup/memory/machine.slice/machine-.scope/memory.limit_in_bytes" outputs 2147483648 4) nsenter -t -m -u -i -n -p free reports 2097152 kB 5) ssh container.example.com free reports 9007199254740991 kB 3) cat "/sys/fs/cgroup/memory/machine.slice/machine-.scope/memory.limit_in_bytes" outputs 9223372036854771712 6) nsenter -t -m -u -i -n -p free reports 9007199254740991 kB 7) virsh -c lxc:// memtune container.example.com reports a hard_limit of unlimited As far as I can tell it seems to be that systemd unsets the cgroup memory limit when creating the user session. However why it gets set to 9223372036854771712 instead of the 255G of the host I don't know. In any case I am looking forward to a better solution than resetting the limits through cron every minute. -- Package-specific info: -- System Information: Debian Release: 9.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-0.bpo.5-amd64 (SMP w/32 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.115 ii libacl1 2.2.52-3+b1 ii libapparmor1 2.11.0-3 ii libaudit1 1:2.6.7-2 ii libblkid1 2.29.2-1 ii libc6 2.24-11+deb9u1 ii libcap2 1:2.25-1 ii libcryptsetup4 2:1.7.3-4 ii libgcrypt20 1.7.6-2+deb9u2 ii libgpg-error0 1.26-2 ii libidn11 1.33-1 ii libip4tc0 1.6.0+snapshot20161117-6 ii libkmod2 23-2 ii liblz4-1 0.0~r131-2+b1 ii liblzma5 5.2.2-1.2+b1 ii libmount1 2.29.2-1 ii libpam0g 1.1.8-3.6 ii libseccomp2 2.3.1-2.1 ii libselinux1 2.6-3+b3 ii libsystemd0 232-25+deb9u1 ii mount 2.29.2-1 ii procps 2:3.3.12-3 ii util-linux 2.29.2-1 Versions of packages systemd recommends: ii dbus 1.10.24-0+deb9u1 ii libpam-systemd 232-25+deb9u1 Versions of packages systemd suggests: pn policykit-1 pn systemd-container pn systemd-ui Versions of packages systemd is related to: pn dracut pn initramfs-tools ii udev 232-25+deb9u1 -- no debconf information ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#890824: Container: unsets cgroup memory limit on user login
Am 19.02.2018 um 13:09 schrieb Maximilian Philipps: > Package: systemd > Version: 232-25+deb9u1 > Severity: important > > Hi > > I have an issue with Systemd unsetting the memory limit for my container, > whereupon programs like free and htop report having access to 8 exabyte > of memory. > > The setup is the following: > > Host: > Release: Debian jessie > Kernel: 4.9.65-3+deb9u2~bpo8+1 (jessie backports) > Container provider: libvirt 3.0.0-4~bpo8+1 (jessie backports) > Systemd: 215-17+deb8u7 (jessie) > cgroup hierarchy: legacy > > Guest: > Release: Debian stretch > Systemd: 232-25+deb9u1 (stretch) > > There are several containers running on the host, but this problem only > occurs with all the Debian stretch containers. Containers running Debian > jessie or older Ubuntu 12.04 aren't affected. > Each container is configured to cgroup enforced memory limit in it's > libvirt domain file. > Example: > 4194304 > 2097152 > > Steps to reproduce + observations: > 1) start a container with virsh -c lxc:// container.example.com > 2) virsh -c lxc:// memtune container.example.com > reports a hard_limit of 2097152 > 3) cat > "/sys/fs/cgroup/memory/machine.slice/machine-.scope/memory.limit_in_bytes" > > outputs 2147483648 > 4) nsenter -t -m -u -i -n -p free reports 2097152 kB > 5) ssh container.example.com free reports 9007199254740991 kB > 3) cat > "/sys/fs/cgroup/memory/machine.slice/machine-.scope/memory.limit_in_bytes" > > outputs 9223372036854771712 > 6) nsenter -t -m -u -i -n -p free reports 9007199254740991 kB > 7) virsh -c lxc:// memtune container.example.com > reports a hard_limit of unlimited > > As far as I can tell it seems to be that systemd unsets the cgroup memory > limit when creating the user session. However why it gets set to > 9223372036854771712 instead of the 255G of the host I don't know. I'm confused: Are you saying that systemd inside the guest (i.e. running systemd v232) resets the memory limits on the host (running v215)? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#890824: Container: unsets cgroup memory limit on user login
On 02/19/2018 01:50 PM, Michael Biebl wrote: Am 19.02.2018 um 13:09 schrieb Maximilian Philipps: Package: systemd Version: 232-25+deb9u1 Severity: important Hi I have an issue with Systemd unsetting the memory limit for my container, whereupon programs like free and htop report having access to 8 exabyte of memory. The setup is the following: Host: Release: Debian jessie Kernel: 4.9.65-3+deb9u2~bpo8+1 (jessie backports) Container provider: libvirt 3.0.0-4~bpo8+1 (jessie backports) Systemd: 215-17+deb8u7 (jessie) cgroup hierarchy: legacy Guest: Release: Debian stretch Systemd: 232-25+deb9u1 (stretch) There are several containers running on the host, but this problem only occurs with all the Debian stretch containers. Containers running Debian jessie or older Ubuntu 12.04 aren't affected. Each container is configured to cgroup enforced memory limit in it's libvirt domain file. Example: 4194304 2097152 Steps to reproduce + observations: 1) start a container with virsh -c lxc:// container.example.com 2) virsh -c lxc:// memtune container.example.com reports a hard_limit of 2097152 3) cat "/sys/fs/cgroup/memory/machine.slice/machine-.scope/memory.limit_in_bytes" outputs 2147483648 4) nsenter -t -m -u -i -n -p free reports 2097152 kB 5) ssh container.example.com free reports 9007199254740991 kB 3) cat "/sys/fs/cgroup/memory/machine.slice/machine-.scope/memory.limit_in_bytes" outputs 9223372036854771712 6) nsenter -t -m -u -i -n -p free reports 9007199254740991 kB 7) virsh -c lxc:// memtune container.example.com reports a hard_limit of unlimited As far as I can tell it seems to be that systemd unsets the cgroup memory limit when creating the user session. However why it gets set to 9223372036854771712 instead of the 255G of the host I don't know. I'm confused: Are you saying that systemd inside the guest (i.e. running systemd v232) resets the memory limits on the host (running v215)? No, the hosts still sees the 255GB. The systemd in the guest resets the limits for the container when someone logs in. In terms of the cgroup hierarchy /sys/fs/cgroup/memory/memory.limit_in_bytes is always 9223372036854771712, which appears to be treated as no restrictions on the host. However the memory.limit_in_bytes within the machine scope does change. ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#890824: Container: unsets cgroup memory limit on user login
On 02/19/2018 02:07 PM, Maximilian Philipps wrote: On 02/19/2018 01:50 PM, Michael Biebl wrote: Am 19.02.2018 um 13:09 schrieb Maximilian Philipps: Package: systemd Version: 232-25+deb9u1 Severity: important Hi I have an issue with Systemd unsetting the memory limit for my container, whereupon programs like free and htop report having access to 8 exabyte of memory. The setup is the following: Host: Release: Debian jessie Kernel: 4.9.65-3+deb9u2~bpo8+1 (jessie backports) Container provider: libvirt 3.0.0-4~bpo8+1 (jessie backports) Systemd: 215-17+deb8u7 (jessie) cgroup hierarchy: legacy Guest: Release: Debian stretch Systemd: 232-25+deb9u1 (stretch) There are several containers running on the host, but this problem only occurs with all the Debian stretch containers. Containers running Debian jessie or older Ubuntu 12.04 aren't affected. Each container is configured to cgroup enforced memory limit in it's libvirt domain file. Example: 4194304 2097152 Steps to reproduce + observations: 1) start a container with virsh -c lxc:// container.example.com 2) virsh -c lxc:// memtune container.example.com reports a hard_limit of 2097152 3) cat "/sys/fs/cgroup/memory/machine.slice/machine-.scope/memory.limit_in_bytes" outputs 2147483648 4) nsenter -t -m -u -i -n -p free reports 2097152 kB 5) ssh container.example.com free reports 9007199254740991 kB 3) cat "/sys/fs/cgroup/memory/machine.slice/machine-.scope/memory.limit_in_bytes" outputs 9223372036854771712 6) nsenter -t -m -u -i -n -p free reports 9007199254740991 kB 7) virsh -c lxc:// memtune container.example.com reports a hard_limit of unlimited As far as I can tell it seems to be that systemd unsets the cgroup memory limit when creating the user session. However why it gets set to 9223372036854771712 instead of the 255G of the host I don't know. I'm confused: Are you saying that systemd inside the guest (i.e. running systemd v232) resets the memory limits on the host (running v215)? No, the hosts still sees the 255GB. The systemd in the guest resets the limits for the container when someone logs in. In terms of the cgroup hierarchy /sys/fs/cgroup/memory/memory.limit_in_bytes is always 9223372036854771712, which appears to be treated as no restrictions on the host. However the memory.limit_in_bytes within the machine scope does change. On a second thought, maybe you assumed that the cgroup namespace is unshared? This is not the case, cgroup namespaces are fairly new and as far as I know not supported by libvirt-lxc. ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: bug 890641 is forwarded to https://github.com/systemd/systemd/issues/8221
Processing commands for cont...@bugs.debian.org: > forwarded 890641 https://github.com/systemd/systemd/issues/8221 Bug #890641 [udev] udev: fragile handling of uevent actions breaks with kernel 4.12+ Set Bug forwarded-to-address to 'https://github.com/systemd/systemd/issues/8221'. > thanks Stopping processing here. Please contact me if you need assistance. -- 890641: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890641 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#763401: Direktoriaus kontaktai - tai Jūsų klientas
Laba diena, Noriu Jus informuoti apie šių metų pasikeitimą dėl atnaujintos visos Lietuvos įmonių bazės 2018 metų sausio vidurio. Visi juridiniai asmenys pateikti bazėje yra veikiantys, realiai vykdantys veiklą, turintys įdarbintų darbuotojų. Duomenys pagal Sodrą, Registrų centrą. Bazėje nurodoma ir apyvarta, darbuotojų atlyginimai, darbuotojų skaičius, transporto skaičius ir daug kitų duomenų, kuriuos matysite pavyzdyje. Duomenis galima filtruoti pagal veiklas, miestus ir kitus duomenis. Šią bazę verta turėti visoms įmonėms. Pateiksiu priežastis: 1) Kontaktai pateikti bazėje direktorių ir kitų atsakingų asmenų, didelė tikimybė Jums surasti naujų klientų, partnerių, tiekėjų, kai tiesiogiai bendrausite su direktoriais, komercijos vadovais. 2) Konkurentų analizavimas, tiekėjų atsirinkimas pagal Jums reikalingus kriterijus, galite atsifiltruoti pagal įmonės dydį, bazėje nurodoma kiek įmonės skolingos Sodrai. 3) Lengva, greita ir patogu dirbti su šia baze, elektroninius pašto adresus galite importuoti į elektroninių laiškų siuntimo programas ar sistemas iš kurių siunčiate elektroninius laiškus. Taip pat galite importuoti mobiliųjų telefonų numerius į SMS siuntimo programas. Išsirinkite iš "Veiklų sąrašo" veiklas kurių Jums reikia. ( Sąrašas prisegtas laiške excel faile ) Parašykite, kurias veiklas išsirinkote ir atsiųsime pavyzdį ir pasiūlymą su sąlygomis įmonių bazei įsigyti Pagarbiai, Tadas Giedraitis Tel. nr. +37067881041 Veiklos.xlsx Description: Binary data ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
