Re: [systemd-devel] How to disable Predictable Network Interface Names using a drop-in?

2017-03-10 Thread Marc Haber
Hi,

On Mon, Feb 20, 2017 at 05:42:19PM +0100, Lennart Poettering wrote:
> On Mon, 20.02.17 17:38, Lennart Poettering (lenn...@poettering.net) wrote:
> > Consider naming the file 50-lanc0.link or so, so that it takes
> > precedence over 99-default.link if that's shipped by your distro. If
> > it isn't, please contact your downstream distro for help (see above).
> 
> BTW, all of the above is documented in systemd.link(5). My
> recommendation is always to check the documentation first.

Just to put and end to this, with proper numbering things are just
fine now. Having this part ot systemd working in lexical order was
just a surprise, I didn't expect that.

Btw, the word "link" is multiply used in IT, so one can expect people
to think of the wrong meaning of the word if one uses it without more
explanation.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Remove me please

2017-03-10 Thread 4028040024
Sorry if it's any inconvenience,  I signed up accidentally. ___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd debug out of memory

2017-03-10 Thread Michal Sekletar
On Sun, Mar 5, 2017 at 3:59 PM, Pascal Kolijn  wrote:
> Peace,
>
> On 28/02/2017 16:00, Lennart Poettering wrote:
>> On Tue, 28.02.17 13:26, Pascal kolijn (p.kol...@vu.nl) wrote:
>>
>>> Hi List,
>>>
>>> I've subscribed to this list to ask for help in debugging a problem we
>>> seem to have with the socket activated telnetd on a rhel7 system.
>>>
>>> A default install of telnetd collects data from some small boxes
>>> deployed in the field. It works for a long time and then suddenly:
>>>
>>> Feb 26 17:46:53 bibr systemd: Created slice user-6006.slice.
>>> Feb 26 17:46:53 bibr systemd: Starting user-6006.slice.
>>> Feb 26 17:46:53 bibr systemd: Started Session 2223341 of user .
>>> Feb 26 17:46:53 bibr systemd-logind: New session 2223341 of user .
>>> Feb 26 17:46:53 bibr systemd: Starting Session 2223341 of user .
>>> Feb 26 17:46:53 bibr systemd: Started Telnet Server (:28830).
>>> Feb 26 17:46:53 pbibr001 systemd: Starting Telnet Server (:28830)...
>>> Feb 26 17:46:57 bibr systemd: Failed to fork: Cannot allocate memory
>>
>> Hmm, Linux fork() returns ENOMEM if the maximum number of tasks on the
>> system is hit (yes this is a bit misleading, but that's how it is).
>> That max number of tasks is limited for example by the max number of
>> assignable pids as configured in /proc/sys/kernel/pid_max? Maybe you
>> hit that limit? Maybe something is leaking pids on your system? not
>> reaping zombies properly?
>
> As far as I can determine running out of pids is not the issue, as I can
> see pids being reused in a day, which will not say that some may still
> go missing over time, but how do I determine if that is the case...?
>
> What I do see is that the rss of the systemd process is slowly growing
> over time in the production environment. I've not been able (yet) to
> reproduce the situation in a test environment, which is a pity. I think
> I can simulate the telnet connects more accurately after I speak with
> the developer of the said boxes, and see if I can create a reproducible
> situation.
>
>>> Feb 26 17:46:57 bibr systemd: Assertion 'pid >= 1' failed at
>>> src/core/unit.c:1996, function unit_watch_pid(). Aborting.
>>> Feb 26 17:46:57 bibr001 systemd: Caught , cannot fork for core
>>> dump: Cannot allocate memory
>>> Feb 26 17:46:57 bibr systemd: Freezing execution.
>>
>> So this is definitely a bug. If the limit is hit, we hould certainly
>> not hit an assert. I tried to figure out how this could ever happen,
>> but afaics this should not be possible on current git at least. Any
>> chance you can try to reproduce this isue with something more recent
>> than a rhel7 box?
>
> Hmmm, the version we currently use in production is:
>
> # rpm -qa | grep systemd
> systemd-libs-219-19.el7_2.13.x86_64
> systemd-219-19.el7_2.13.x86_64
> systemd-sysv-219-19.el7_2.13.x86_64

I've backported bunch of fixes for memory leaks to
systemd-219-19.el7_2.14. From changelog,

* Mon Aug 22 2016 Lukas Nykryn  - 219-19.14
- core: fix memory leak on set-default, enable, disable etc (#1331667)
- nspawn: fix minor memory leak (#1331667)
- basic: fix error/memleak in socket-util (#1331667)
- core: fix memory leak in manager_run_generators() (#1331667)
- modules-load: fix memory leak (#1331667)
- core: fix memory leak on failed preset-all (#1331667)
- sd-bus: fix memory leak in test-bus-chat (#1331667)
- core: fix memory leak in transient units (#1331667)

Fix is in the code path that is hit everytime you log onto the box,
because every session has its own scope unit.

- bus: fix leak in error path (#1331667)
- shared/logs-show: fix memleak in add_matches_for_unit (#1331667)

>
> I think I can update it to the current state in 7.3 for the production
> machine, but will be reluctant to go for a more recent version...

Those fixes are of course included in 7.3 as well.

Michal

>
> Maybe in the test env, if I can reproduce it there.
>
>> Either way it appears that there's both a bug on your setup and in
>> systemd: something leaks processes (which is bug #1, in your setup)
>> and then systemd doesn't deal properly with that (which is bug #2, in
>> systemd upstream)...
>>
>> Lennart
>>
>
> Pascal Kolijn
> Vrije Universiteit Amsterdam
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to use machinectl to get a running centos container?

2017-03-10 Thread Michal Sekletar
On Fri, Mar 3, 2017 at 4:09 PM, Lennart Poettering
 wrote:
> On Sat, 04.03.17 01:38, Daurnimator (q...@daurnimator.com) wrote:
>
>> On 3 March 2017 at 20:58, Lennart Poettering  wrote:
>> > On Fri, 03.03.17 12:34, Daurnimator (q...@daurnimator.com) wrote:
>> >
>> >> I'm trying to set up a centos 7 container with machinectl.
>> >> I've tried to run:
>> >>
>> >> machinectl pull-raw --verify=no
>> >> http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud-1701.raw.tar.gz
>> >
>> > Hmm, what is a ".raw.tar.gz" file? That suffix makes no sense to me...
>>
>> *shrugs* it's what I saw available for download from
>> http://cloud.centos.org/centos/7/images/
>>
>> Apparently it's a gziped tar with a single file inside:
>> CentOS-7-x86_64-GenericCloud-20170131_01.raw
>> This .raw file is a disk image.
>
> That appears a bit redundant, and importd/machinectl pull-raw is not
> able to handle this.
>
>
>> > We support raw disk images and tarballs with OS trees in them, both
>> > compressed and non-compressed.
>> >
>> > There's currently a safety limit against overly large images enforced,
>> > of 8GiB. If the indicated image is larger than that, and that's
>> > intended we should probably bump this safety limit substantially (32G?
>> > 64G?), please file a github issue asking for this if this is the
>> > case. Or even better prep a PR, the fix is trivial:
>> >
>> > https://github.com/systemd/systemd/blob/master/src/import/pull-job.c#L530
>>
>> Looks like it's *equal* to the limit.
>>
>> Before I make a PR here, am I going about running a centos container
>> with machinectl the best way here?
>> How are other people doing this?
>
> I don't think many people are using CentOS caontainers with
> nspawn... That said, there's a good chance that it works OKish.

I use them regularly and they work just fine (well I use RHEL7 but
that should not matter). However I don't download images from
anywhere. I install distro trees to /var/lib/machines/ manually using
dnf.

>
> Note that "machinectl pull-raw" is just a helper to make downloading
> easy. But if you have images in weird formats, you can download them
> and place them in /var/lib/machines (with the .raw suffix), and
> machined/nspawn is happy. It doesn't really matter how the image gets
> there as long as it gets there, and "machinectl pull-raw" is just one
> way.

That is what I also recommend. Installing from repo always worked for
me. For basic system container I just use example from nspawn manpage.

Michal

>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] mount-on-demand for backups; hooks for indicating success/failure

2017-03-10 Thread Michal Sekletar
On Thu, Mar 9, 2017 at 4:53 PM, Jonathan Dowland
 wrote:
> Hey,
>
> I have some backup services which depend on mounts. I want those
> filesystems unmounted when the backup jobs are not running. This is
> easily achieved with StopWhenUnneeded.
>
> I also want to trigger the backup jobs to start when I attach my
> external HDD. This is reasonably simple by adding WantedBy=
> to the backup service (*not* the mount unit, or it will never be
> auto-unmounted).

WantedBy=device sounds like a weird hack to me. I think that it would
be better to use SYSTEM_WANTS in udev rules instead.

>
> So far so good!
>
> However, this is a headless box and I want to blink an LED when certain
> jobs are running, finish or fail. So I need to execute commands in
> certain situations. Job failure is easy, I can use OnFailure= and set up
> a oneshot service. Job started isn't too bad, I add a ExecStart=-
> to my backup service before the real one.

OnFailure is fine and ExecStart before starting backup also sounds reasonable.

>
> Signalling "device is safe to remove" I have not figured out.
> Using a chain of blah.device -> blah.mount -> backup-blah.service units,
> "safe to remove" LED should only happen after the mount has completed
> unmounting, successfully. Is there an existing "hook" or place that I
> could put that in this situation?

It should be possible to achieve this with normal dependencies. For
example, you would have blink-successful.service that would Require
backup service and would be ordered after it.

Dependencies should then look like this,
# backup.service
[Unit]
Wants=blink-successful.service

# blink-successful.service,
[Unit]
Requires=backup.service
After=backup.service

backup.service pulls in blink service and that will run only when
backup succeeded.

>
> My temporary solution is to remove the mount unit entirely, define the
> mount point in /etc/fstab and use ExecStart and ExecStop in the backup
> service to mount and umount before and after the job runs:
>
> [Unit]
> OnFailure=blinkstick-fail.service
> [Service]
> ExecStart=/bin/mount /media/ipod

I'd leave fstab entry in place and replace ExecStart=/bin/mount with
RequiresMountsFor=/media/ipod (this belongs to [Unit] section). So
when this service is started it will pull in mount unit to transaction
and gets ordered after the mount unit.

Michal
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel