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

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

[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] unsubsribe

[Douglas R. Reno]

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

>
>
> 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:
>>  ,
>>  
>>
>>
>>
> 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
>
>
That is a good point. I hadn't caught that.
___
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

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 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:
 ,
 
___
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

[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] 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

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] 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] PAM session hooks for independent session

[Lennart Poettering]

On Sat, 29.10.16 18:37, Antoine Martin (anto...@nagafix.co.uk) wrote:

> The pam_systemd is much more difficult to figure out, since I am not
> aware of any other packages does this at present - maybe there are?
> * should we ship a /etc/pam/d/xpra file like this one:
> sessionrequired pam_localuser.so
> sessionsufficient pam_systemd.so class=user type=x11 debug=1
> * we supply VTNR=0 (we don't have a VT..), XDG_SESSION_TYPE=x11,
> XDG_SEAT=0 (not sure this is right) as well as the correct PAM_XDISPLAY
> for the display we've started. But the pam_open_session call fails with:
> pam_systemd(xpra:session): Failed to create session: Access denied
> Probably because of this:

You should not set the vtnr or seat name, if you are fully virtual and
do not manage local hw or local vts.

> [system] Rejected send message, 2 matched rules; type="method_call",
> sender=":1.339" (uid=1001 pid=15738 comm="/bin/python /usr/bin/xpra
> start --systemd-run=yes "
> label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
> interface="org.freedesktop.login1.Manager" member="CreateSession" error
> name="(unset)" requested_reply="0" destination="org.freedesktop.login1"
> (uid=0 pid=1185 comm="/usr/lib/systemd/systemd-logind "
> label="system_u:system_r:systemd_logind_t:s0")
> 
> Where / how can we change the policy to allow sufficiently privileged
> users to create a new session? (which users will get this privilege and
> how this is configured is not entirely clear at this point - can we
> somehow keep this simple using unix group permissions?)
> How is this going to ensure that the cgroup is correct? Isn't that set
> when the process is started?
> 
> Any help or pointers would be much appreciated.

Registering sessions requires privileges. If you want unprivileged
clients to be able to do this, you need to add a security transition
somewhere. This means your tool can either be SUID (which I wouldn't
recommend) or you split your tool in two: a tiny (socket activated)
daemon that does little else than wait for a client request, and when
it gets it, registers the PAM session and drops privs and runs your
virtual display server. Basically what a display manager such as gdm
does, but instead of managing physical seats you'd just instantiate a
virtual x server for each incoming connection.

Ultimately this is the best idea anyway, as you should properly
disconnect the new bg session from the original session, and that
means you should not have a process relationship between your
processes.

Hope this makes sense=

Lennart

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

[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

[systemd-devel] [ANNOUNCE] systemd 232

[Lennart Poettering]

Hey!

Here's a new release with many new features and even more fixes:

https://github.com/systemd/systemd/archive/v232.tar.gz

CHANGES WITH 232:

* The new RemoveIPC= option can be used to remove IPC objects owned by
  the user or group of a service when that service exits.

* The new ProtectKernelModules= option can be used to disable explicit
  load and unload operations of kernel modules by a service. In
  addition access to /usr/lib/modules is removed if this option is set.

* ProtectSystem= option gained a new value "strict", which causes the
  whole file system tree with the exception of /dev, /proc, and /sys,
  to be remounted read-only for a service.

* The new ProtectKernelTunables= option can be used to disable
  modification of configuration files in /sys and /proc by a service.
  Various directories and files are remounted read-only, so access is
  restricted even if the file permissions would allow it.

* The new ProtectControlGroups= option can be used to disable write
  access by a service to /sys/fs/cgroup.

* Various systemd services have been hardened with
  ProtectKernelTunables=yes, ProtectControlGroups=yes,
  RestrictAddressFamilies=.

* Support for dynamically creating users for the lifetime of a service
  has been added. If DynamicUser=yes is specified, user and group IDs
  will be allocated from the range 61184..65519 for the lifetime of the
  service. They can be resolved using the new nss-systemd.so NSS
  module. The module must be enabled in /etc/nsswitch.conf. Services
  started in this way have PrivateTmp= and RemoveIPC= enabled, so that
  any resources allocated by the service will be cleaned up when the
  service exits. They also have ProtectHome=read-only and
  ProtectSystem=strict enabled, so they are not able to make any
  permanent modifications to the system.

* The nss-systemd module also always resolves root and nobody, making
  it possible to have no /etc/passwd or /etc/group files in minimal
  container or chroot environments.

* Services may be started with their own user namespace using the new
  boolean PrivateUsers= option. Only root, nobody, and the uid/gid
  under which the service is running are mapped. All other users are
  mapped to nobody.

* Support for the cgroup namespace has been added to systemd-nspawn. If
  supported by kernel, the container system started by systemd-nspawn
  will have its own view of the cgroup hierarchy. This new behaviour
  can be disabled using $SYSTEMD_NSPAWN_USE_CGNS environment variable.

* The new MemorySwapMax= option can be used to limit the maximum swap
  usage under the unified cgroup hierarchy.

* Support for the CPU controller in the unified cgroup hierarchy has
  been added, via the CPUWeight=, CPUStartupWeight=, CPUAccounting=
  options. This controller requires out-of-tree patches for the kernel
  and the support is provisional.

* Mount and automount units may now be created transiently
  (i.e. dynamically at runtime via the bus API, instead of requiring
  unit files in the file system).

* systemd-mount is a new tool which may mount file systems – much like
  mount(8), optionally pulling in additional dependencies through
  transient .mount and .automount units. For example, this tool
  automatically runs fsck on a backing block device before mounting,
  and allows the automount logic to be used dynamically from the
  command line for establishing mount points. This tool is particularly
  useful when dealing with removable media, as it will ensure fsck is
  run – if necessary – before the first access and that the file system
  is quickly unmounted after each access by utilizing the automount
  logic. This maximizes the chance that the file system on the
  removable media stays in a clean state, and if it isn't in a clean
  state is fixed automatically.

* LazyUnmount=yes option for mount units has been added to expose the
  umount --lazy option. Similarly, ForceUnmount=yes exposes the --force
  option.

* /efi will be used as the mount point of the EFI boot partition, if
  the directory is present, and the mount point was not configured
  through other means (e.g. fstab). If /efi directory does not exist,
  /boot will be used as before. This makes it easier to automatically
  mount the EFI partition on systems where /boot is used for something
  else.

* When operating on GPT disk images for containers, systemd-nspawn will
  now mount the ESP to /boot or /efi accor