[systemd-devel] [ANNOUNCE] systemd v230

2016-05-21 Thread Zbigniew Jędrzejewski-Szmek 
Hi,

systemd v230 has been tagged. Enjoy!

CHANGES WITH 230:

* DNSSEC is now turned on by default in systemd-resolved (in
  "allow-downgrade" mode), but may be turned off during compile time by
  passing "--with-default-dnssec=no" to "configure" (and of course,
  during runtime with DNSSEC= in resolved.conf). We recommend
  downstreams to leave this on at least during development cycles and
  report any issues with the DNSSEC logic upstream. We are very
  interested in collecting feedback about the DNSSEC validator and its
  limitations in the wild. Note however, that DNSSEC support is
  probably nothing downstreams should turn on in stable distros just
  yet, as it might create incompatibilities with a few DNS servers and
  networks. We tried hard to make sure we downgrade to non-DNSSEC mode
  automatically whenever we detect such incompatible setups, but there
  might be systems we do not cover yet. Hence: please help us testing
  the DNSSEC code, leave this on where you can, report back, but then
  again don't consider turning this on in your stable, LTS or
  production release just yet. (Note that you have to enable
  nss-resolve in /etc/nsswitch.conf, to actually use systemd-resolved
  and its DNSSEC mode for host name resolution from local
  applications.)

* systemd-resolve conveniently resolves DANE records with the --tlsa
  option and OPENPGPKEY records with the --openpgp option. It also
  supports dumping raw DNS record data via the new --raw= switch.

* systemd-logind will now by default terminate user processes that are
  part of the user session scope unit (session-XX.scope) when the user
  logs out. This behavior is controlled by the KillUserProcesses=
  setting in logind.conf, and the previous default of "no" is now
  changed to "yes". This means that user sessions will be properly
  cleaned up after, but additional steps are necessary to allow
  intentionally long-running processes to survive logout.

  While the user is logged in at least once, user@.service is running,
  and any service that should survive the end of any individual login
  session can be started at a user service or scope using systemd-run.
  systemd-run(1) man page has been extended with an example which shows
  how to run screen in a scope unit underneath user@.service. The same
  command works for tmux.

  After the user logs out of all sessions, user@.service will be
  terminated too, by default, unless the user has "lingering" enabled.
  To effectively allow users to run long-term tasks even if they are
  logged out, lingering must be enabled for them. See loginctl(1) for
  details. The default polkit policy was modified to allow users to
  set lingering for themselves without authentication.

  Previous defaults can be restored at compile time by the
  --without-kill-user-processes option to "configure".

* systemd-logind gained new configuration settings SessionsMax= and
  InhibitorsMax=, both with a default of 8192. It will not register new
  user sessions or inhibitors above this limit.

* systemd-logind will now reload configuration on SIGHUP.

* The unified cgroup hierarchy added in Linux 4.5 is now supported.
  Use systemd.unified_cgroup_hierarchy=1 on the kernel command line to
  enable. Also, support for the "io" cgroup controller in the unified
  hierarchy has been added, so that the "memory", "pids" and "io" are
  now the controllers that are supported on the unified hierarchy.

  WARNING: it is not possible to use previous systemd versions with
  systemd.unified_cgroup_hierarchy=1 and the new kernel. Therefore it
  is necessary to also update systemd in the initramfs if using the
  unified hierarchy. An updated SELinux policy is also required.

* LLDP support has been extended, and both passive (receive-only) and
  active (sender) modes are supported. Passive mode ("routers-only") is
  enabled by default in systemd-networkd. Active LLDP mode is enabled
  by default for containers on the internal network. The "networkctl
  lldp" command may be used to list information gathered. "networkctl
  status" will also show basic LLDP information on connected peers now.

* The IAID and DUID unique identifier sent in DHCP requests may now be
  configured for the system and each .network file managed by
  systemd-networkd using the DUIDType=, DUIDRawData=, IAID= options.

* systemd-networkd gained support for configuring proxy ARP support for
  each interface, via the ProxyArp= setting in

Re: [systemd-devel] UEFI menu entries wiped from BIOS after power off at dm-crypt boot prompt

2016-05-21 Thread Mantas Mikulėnas 
On Sat, May 21, 2016 at 11:43 PM, Jamie Kitson  wrote:

> Hi,
>
> if I power off my computer at the dm-crypt boot password prompt my UEFI
> menu entries get wiped from the BIOS and reset to the single default
> Windows option.
>
> This is with an Asus UX32VD laptop, Grub UEFI and systemd and sd-encrypt
> mkinitcpio hooks.
>
> If this isn't a systemd issue could anyone have a guess as to where the
> issue might lie?
>

I'm not sure how this *could* be a systemd issue. The UEFI menu entries are
managed by your firmware (i.e. by UEFI); the only time systemd tools edit
them is when you run `bootctl install`.

Do the entries get wiped if you power off at any other point? If waiting a
few minutes longer avoids the problem, it could be that your firmware is
trying to "recover from failed boot" this way.

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] autostart processes based on tty

2016-05-21 Thread Jonathan de Boyne Pollard 

I would like to start different processes in different ttys on boot,


What you need is a Q WWW site.  (-:

* http://unix.stackexchange.com/questions/211544/
* http://askubuntu.com/questions/770673/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] UEFI menu entries wiped from BIOS after power off at dm-crypt boot prompt

2016-05-21 Thread Jamie Kitson 
Hi,

if I power off my computer at the dm-crypt boot password prompt my UEFI
menu entries get wiped from the BIOS and reset to the single default
Windows option.

This is with an Asus UX32VD laptop, Grub UEFI and systemd and sd-encrypt
mkinitcpio hooks.

If this isn't a systemd issue could anyone have a guess as to where the
issue might lie?

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

Re: [systemd-devel] Failed to restart ntpd

2016-05-21 Thread Kai Krakow 
Am Thu, 12 May 2016 11:51:13 +0200
schrieb Reindl Harald :

> Am 12.05.2016 um 11:46 schrieb liuxueping:
> > Before i restart ntpd,ntpd process was running:
> > ntp   3993  0.0  0.0   7404  4156 ?Ss   10:21   0:00
> > /usr/sbin/ntpd -u ntp:ntp -g
> > root  3995  0.0  0.0   7404  2364 ?S10:21   0:00
> > /usr/sbin/ntpd -u ntp:ntp -g
> > so,it should be killed by systemctl and restart a new ntpd
> > process,but it failed,i want to know systemd how to judge that a
> > process is killed completed to start a new service.  
> 
> again: systemd monitors all processes part of a service
> systemctl itself does nothing, it just invokes commands
> 
> when you manually started a ntpd process systemd don't know it should
> be killed and *it should not* get killed just because "systemctl
> restart ntpd"
> 
> so when there is a ntpd process which is not listed in "systemctl 
> status" you or something has manually fired up that process - don't
> do that at all - and you need to kill it the same way

This situation may also happen, if shell scripts provide services and
try to do funny things like "su - $user" to switch to another user. This
creates a new session, PIDs started there seem not to be tracked by
systemd as part of the service. Reliable teardown by systemd is then
broken.

I had this problem with dccifd whose scripts try to be extraordinary
smart and reinvent the wheel.


-- 
Regards,
Kai

Replies to list-only preferred.


pgpGLnGmNJexQ.pgp
Description: Digitale Signatur von OpenPGP
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] launching an interactive user session

2016-05-21 Thread Andrei Borzenkov 
20.05.2016 23:10, Mike Gulick пишет:
> Hi systemd-devel,
> 
> I'm on Debian Jessie running the default systemd-215.  I have a
> daemon (running as root, controlled by systemd), whose job it is to
> launch on-demand VNC servers for other users.  Currently, this daemon
> uses a shell command like the following to launch the vnc server for
> a given $USER:
> 
> sudo -i -u $USER /bin/sh -l -c 'cd \$HOME && /path/to/vncserver
> $ARGS
> 
> The issue I'm having is that the user VNC sessions being created all
> share the same systemd login session as my daemon.  I can see this by
> running systemd-cgls.  The users of these VNC sessions would like to
> be able to use "systemd-run --user --scope -p MemoryLimit=X COMMAND"
> to launch a command with cgroup-based resource limiting.  However
> without a user session, this results in "Failed to create bus
> connection: Connection refused".
> 
> There's too many users to create static systemd unit files, and it
> doesn't seem like I can create and load .service files on the fly.
> The "machinectl shell" command
> (https://github.com/systemd/systemd/pull/1022) looks promising, but
> unfortunately it's not in my systemd yet.  I've tried searching
> through this mailing list's history, but the results all were dead
> ends.
> 
> It seems like there's a lot of pieces needed to make this work (dbus,
> XDG env vars, systemd --user), and all of the recommendations say to
> go through pam_systemd.so.  I'm not afraid of interacting with PAM,
> but I don't really understand what's needed, and I can't actually
> authenticate as the user because I don't know their password
> (currently this daemon is root so it doesn't need a password to
> switch user).
> 
> If there is some kind of shell pipeline, or a wrapper script I can
> write to automate the necessary steps please let me know.
> 

Rather heavy weight solution is to enable lingering for all users in
question. In this case user instance is started automatically when
system boots and persists until system shutdown. VNC can then be started
as user-level service.

I believe recently there was discussion about global knobs to enable
lingering for all users at once.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] restart vs. stop/start

2016-05-21 Thread Andrei Borzenkov 
21.05.2016 05:59, Reindl Harald пишет:
> 
> 
> Am 20.05.2016 um 21:50 schrieb Christian Boltz:
>> Hello,
>>
>> it looks like
>> systemctl restart foo
>> is internally mapped to a sequence of
>> systemctl stop foo; systemctl start foo
> 
> what else?
> 
>> Unfortunately, this behaviour causes quite some trouble for me.
> 
> why?
> 

If you bothered to read URL OP mentioned, you would see one possible reason.

>> I need a way to know if "restart "or "stop" was used because the mapping
>> to stop / start gives my service a completely different behaviour than
>> expected on restart.
>>
>> Is there a way to find out if "stop" or "restart" was used?
> 
> if you need to differ here your service is broken by design - why do you
> need to kow what triggered stop and what else do you imagine for
> "restart" then stop-start?
> 

I am curious how you implement "systemctl daemon-restart" using only
plain "stop systemd" followed by "start systemd".
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel