[systemd-devel] systemd-nspawn leaves leftovers in /tmp

[Bill Lipa]

Hello,

I am using systemd-nspawn to run a short lived process in a container.
This is a fairly frequent operation (once every few seconds).  Each
time systemd-nspawn runs, it leaves a temporary empty directory like
/tmp/nspawn-root-CPeQjR.  These directories don't seem to get cleaned
up.

I'm using systemd 229 on Ubuntu 16.04.  The command line looks like:

sudo systemd-nspawn -axq --private-network --drop-capability=all -u user
  --chdir /home/user/work -M ubuntu-16.10 --bind
/home/outer/work:/home/user/work

I'm a little worried that there are going to be hundreds of thousands
of these directories clogging up /tmp after a few weeks.  Is this
expected?

Thank you!
Bill Lipa
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-nspawn leaves leftovers in /tmp

[Lennart Poettering]

On Thu, 03.11.16 11:34, Bill Lipa (d...@masterleep.com) wrote:

> Hello,
> 
> I am using systemd-nspawn to run a short lived process in a container.
> This is a fairly frequent operation (once every few seconds).  Each
> time systemd-nspawn runs, it leaves a temporary empty directory like
> /tmp/nspawn-root-CPeQjR.  These directories don't seem to get cleaned
> up.
> 
> I'm using systemd 229 on Ubuntu 16.04.  The command line looks like:
> 
> sudo systemd-nspawn -axq --private-network --drop-capability=all -u user
>   --chdir /home/user/work -M ubuntu-16.10 --bind
> /home/outer/work:/home/user/work
> 
> I'm a little worried that there are going to be hundreds of thousands
> of these directories clogging up /tmp after a few weeks.  Is this
> expected?

Generally, temporary files like this should not be left around by
commands that exit cleanly. If they do, then that's a bug, please file
a bug. (but first, please retry on the two most current systemd
versions, we only track issues with those upstream).

Lennart

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

Re: [systemd-devel] kexec -p option does not cause a reboot on panic

[Lennart Poettering]

On Sat, 29.10.16 00:16, Dey, Megha (megha@intel.com) wrote:

> Hi,
> 
> I was testing kexec on systemd (Ubuntu 16.04). Here are the steps I follow:

systemd is not involved with crash dumping on kernel crashes. Please
contact your distro maintainers or the crash dumping maintainers for
help, we can't really help you there.

Sorry,

Lennart

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

Re: [systemd-devel] automount unit that never fails?

[Lennart Poettering]

On Sat, 29.10.16 14:20, Bjørn Forsman (bjorn.fors...@gmail.com) wrote:

> On 1 October 2016 at 17:14, Bjørn Forsman  wrote:
> > On 20 September 2016 at 09:08, Bjørn Forsman  
> > wrote:
> >> I have a question/issue with the behaviour of (auto)mount units.
> >> [...]
> >
> > Bump.
> 
> Bump again. Anyone?

Your mail does not say in any way what precisely your issue is?

Lennart

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

[systemd-devel] unsubsribe

[sp113438]

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

Re: [systemd-devel] Single Start-job remains listed after startup in state waiting ...

[Lennart Poettering]

On Fri, 28.10.16 14:55, Hoyer, Marko (ADITG/SW2) (mho...@de.adit-jv.com) wrote:

> Hello,
> 
> we are observing a weird  behavior with systemd 211.
> 
> The issue:
> 
> -After the startup is finished (multi-user.target is
> -reached), one single job (typ: start, unit: service)
> -remains in the job queue in state waiting

We had an issue with that in the past, please retry with a less
ancient version of systemd, I am pretty sure this was already fixed,
but I can't tell you really when precisely.

Lennart

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

Re: [systemd-devel] unsubsribe

[Douglas R. Reno]

On Thu, Nov 3, 2016 at 3:10 PM, Reindl Harald 
wrote:

>
>
> Am 03.11.2016 um 20:27 schrieb sp113438:
>
>> unsubsribe
>>
>
> i can' remember that you asked me or other list memeber to subscribe you
> so why should we even be able to unsubscribe you? guess what the list
> footer is for
>
>
> List-Unsubscribe:
>  ,
>  
>
>
sp113438 misspelled Unsubscribe.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] unsubsribe

[Reindl Harald]

Am 03.11.2016 um 21:36 schrieb Douglas R. Reno:


On Thu, Nov 3, 2016 at 3:10 PM, Reindl Harald > wrote:




Am 03.11.2016 um 20:27 schrieb sp113438:

unsubsribe


i can' remember that you asked me or other list memeber to
subscribe you so why should we even be able to unsubscribe you?
guess what the list footer is for


List-Unsubscribe:
 >,
 ?subject=unsubscribe>



sp113438 misspelled Unsubscribe


correct spelling would not have changed the fact that the list-address 
is ust the wrong destination - on every maling lisst - simply by using 
common-sense
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Question regarding systemd behavior during shutdown

[svk]

Hi,
I have a question regarding systemd behavior during shutdown.

I am using systemd 219 on a Linux 4.1 kernel(custom distribution). When I
issue a "shutdown" command I observe something unusual :-

If a process managed by a systemd unit file with "Restart=always" exits
prior to receiving a SIGTERM, systemd attempts to restart the service.
However, since the system is shutting down, systemd detects a conflict with
shutdown.target, and declares that the service had entered "failed" state.
Wouldn't it be cleaner to detect this before attempting to execute the
restart job? A service voluntarily exiting during shutdown should not be
considered as a failure.

Sample journal logs with detailed output enabled:-

Sep 22 22:59:34 re0 systemd[1]: foo.service holdoff time over, scheduling
restart.

33937 Sep 22 22:59:34 re0 systemd[1]: Trying to enqueue job
foo.service/restart/fail

Sep 22 22:59:34 re0 systemd[1]: Requested transaction contradicts existing
jobs: Transaction is destructive

Sep 22 22:59:34 re0 systemd[1]:foo.service failed to schedule restart job:
Transaction is destructive.

Sep 22 22:59:34 re0 systemd[1]: foo.service changed auto-restart -> failed
Thanks,
Shreyas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

[Lennart Poettering]

On Mon, 26.09.16 07:02, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:

> On Mon, Sep 26, 2016 at 10:52:50AM +1300, Sergei Franco wrote:
> > The emergency mode assumes console access, which requires physical access,
> > which is quiet difficult if the machine is remote.
> 
> It does also assume knowledge of the root password, which is in
> enterprise environments not often the case. Enterprises usually have
> root passwords stowed away in a safe, behind a three-headed guard dog,
> requiring management approval, and > 2 eyes mechanisms, and usually
> have password-changing processes attached that touch other machines
> sharign the same root password as well (for example because the root
> password hash is stamped into the golden image).
> 
> Many enterprise environments that I know have their processes geared
> in a way that the root password is not needed in daily operation.
> Login via ssh key, privilege escalation via sudo.
> 
> systemd requiring the root password because some tertiary file system
> doesn't mount is a nuisance for those environments.
> 
> Some sites have resorted to adding "nofail" to all fstab lines just to
> find themselves with the next issue since the initramfs of some
> distributions doesn't know this option yet. 

"nofail" has been around as long as fstab has been around really. It's
not a systemd invention.

Lennart

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

Re: [systemd-devel] Question regarding systemd behavior during shutdown

[Lennart Poettering]

On Thu, 03.11.16 14:01, svk (shreyas...@gmail.com) wrote:

> Hi,
> I have a question regarding systemd behavior during shutdown.
> 
> I am using systemd 219 on a Linux 4.1 kernel(custom distribution). When I
> issue a "shutdown" command I observe something unusual :-

219 is really old, and the behaviour regarding the shutdown
transaction has changed a bit in the past. Any chance you can verify
this with something recent before we look into this?

Thanks,

Lennart

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