Re: [systemd-devel] Time synchronization over HTTP?

2016-07-05 Thread Lennart Poettering
On Mon, 27.06.16 10:34, Kai Hendry (hen...@webconverger.com) wrote:

> Hi there,
> 
> I had a quick look at
> https://github.com/systemd/systemd/tree/master/src/timesync to try work
> out if /usr/lib/systemd/systemd-timesyncd had some sort of fallback if
> ntp UDP port 123 traffic is blocked.
> 
> This happens all too often with my deployments of Webconverger and I was
> wondering if asking for HTTP based time synchronization was a sane thing
> to ask for from systemd.
> 
> An example implementation can be found here:
> https://github.com/ccrisan/motioneyeos/blob/master/board/common/overlay/etc/init.d/S50date#L31

I figure having something like this makes some sense. There was a plan
to add something like an http-based ping scheme to networkd, so that
networkd can do captive portal detection natively, and at the same
time acquire some useful data from the ping server, for example a
suggested default timezone/language/location and so on, via some http
request or so. NetworkManager, Firefox, and so on all implement that
on their own these days, to limit degrees, and even ConnMan has been
doing this for quite some time. It's a bit of a privacy issue, as when
this is enabled there's an instant ping to some central server
attempted, but I still think for many setups having this makes a ton
of sense.

I figure using this as also as crappy fallback if NTP doesn't work and
hasn't worked in a while definitely makes sense.

I am not convinced however to reuse some HTTP server for this that
isn't actually explicitly set up for this scheme, and thus is known to
provide correct times. For example, making clients sync their clocks
to www.google.com appears a questionnable idea to me.

So yeah, I like the idea, but doing this properly is not trivial I
figure, in particular if we want to take the privacy issue into
account and provide a at least a bit of anonymity for clients.

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] Samba Server dosen't start

2016-07-05 Thread Lennart Poettering
On Sun, 26.06.16 14:28, Reindl Harald (h.rei...@thelounge.net) wrote:

> 
> 
> Am 26.06.2016 um 14:16 schrieb Tom H:
> >On Sun, Jun 26, 2016 at 8:09 AM, Reindl Harald  
> >wrote:
> >>Am 26.06.2016 um 13:27 schrieb Ralf Recktenwald:
> >>>
> >>>Smb.conf
> >>
> >>how is that a systemd problem?
> >>
> >>how do you imagine help without mention distrubition, software-versions,
> >>cotent of the systemd-unit, systemctl status servicename and so on?
> >
> >The problem's this journalctl output: "Support:
> >http://lists.freedesktop.org/mailman/listinfo/systemd-devel;
> 
> well, that's indeed a braindead output when some rnadom service fails

Yeah, these catalog entries should be improved. As first step with
v231 downstream can easily override the support URL at build time via
a configure script so that the support URL for things like this at
least doesn't end up with us anymore...

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] does "Before=network.target" really work

2016-07-05 Thread Lennart Poettering
On Fri, 24.06.16 18:53, Xin Long (lucien@gmail.com) wrote:

> 
> but I can find some services are truly using it now:
> $ grep "Before=network.target" . -R
> ./wpa_supplicant.service:Before=network.target
> ./NetworkManager.service:Before=network.target
> ./NetworkManager-wait-online.service:Before=network.target 
> network-online.target
> ./arp-ethers.service:Before=network.target
> ./firewalld.service:Before=network.target

The line for firewalld appears wrong btw. The firewall should really
be up before the network is even initiated. Hence it should be
Before=network-pre.target.

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] does "Before=network.target" really work

2016-07-05 Thread Lennart Poettering
On Fri, 24.06.16 18:41, Xin Long (lucien@gmail.com) wrote:

> On Fri, Jun 24, 2016 at 6:23 PM, Andrei Borzenkov  wrote:
> > On Fri, Jun 24, 2016 at 1:11 PM, Xin Long  wrote:
> >> Hi,
> >>
> >> I have a service, and want it to be stopped only after network is
> >> stopped when system shutdown.
> >>
> >> I checked "man systemd.special ", network is a special internal
> >> service for systemd, , and I found "network.target":
> >> "at shutdown, a unit that is ordered after network.target will be
> >> stopped before the network -- to whatever  level it might be set up
> >> then -- is shut down".
> >> That means "After=network.target" can work well.
> >>
> >> But my situation is opposite to that, I need "a unit that is ordered
> >> before network.target will be stopped *after* the network so
> >> shutdown".
> >>
> >> So I added "Before=network.target" to .service file. can it really
> >> work as I expect?
> >>
> >
> > No. That is why systemd was forced to introduce additional
> > network-pre.target to make it possible to explicitly order things
> > before networking is started (or stop after networking has been
> > stopped - assuming of course that all services that implement
> > networking correct order themselves After network-pre.target).
> 
> So you mean "Before=network-pre.target" can work on my case, right ?

Yes, that's what it is for. Also make sure to actually pull in the
target from your service too. Hence you want:

Before=network-pre.target
Wants=network-pre.target

n-p.t is a target that is "passive", it needs to be pulled in by the
implementor of such a service, not by the consumer of it. This has the
benefit that as long as no service wants to hook into this nothing is
added to the transactions for bootup and shutdown and thus more can be
parallelized as one synchronization points less is in the queue.

See systemd.special(7) about it as well as
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

> >> I have a service, and want it to be stopped only after network is
> >> stopped when system shutdown
> 
> and since which version "network-pre.target" was introduced ?
> cause I didn't find it in "man systemd.special" in my system.

This has been addedin systemd 214.

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] How to set a limit for mounting roofs?

2016-07-05 Thread Lennart Poettering
On Mon, 04.07.16 12:32, Chris Murphy (li...@colorremedies.com) wrote:

> I have a system where I get an indefinite
> 
> "A start job is running for dev-vda2.device (xmin ys / no limit)"
> 
> Is there a boot parameter to use to change the no limit to have a
> limit? rd.timeout does nothing. When I use rd.break=pre-mount and use
> blkid, /dev/vda2 is there and can be mounted with the same mount
> options as specified with rootflags= on the command line. So I'm not
> sure why it's hanging indefinitely. I figure with
> systemd.log_level=debug and rd.debug and maybe rd.udev.debug I should
> be able to figure out why this is failing to mount.

It should be possible to use x-systemd.device-timeout= among the mount
options in rootflags= to alter the timeout for the device.

But what precisely do you expect to happen in this case? You'd simply
choose between "waits forever" and "fails after some time"... A
missing root device is hardly something you can just ignore and
proceed...

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] How to set a limit for mounting roofs?

2016-07-05 Thread Lennart Poettering
On Tue, 05.07.16 14:00, Chris Murphy (li...@colorremedies.com) wrote:

> On Tue, Jul 5, 2016 at 12:45 PM, Chris Murphy  wrote:
> > OK it must be this.
> >
> > :/# cat /usr/lib/udev/rules.d/64-btrfs.rules
> > # do not edit this file, it will be overwritten on update
> >
> > SUBSYSTEM!="block", GOTO="btrfs_end"
> > ACTION=="remove", GOTO="btrfs_end"
> > ENV{ID_FS_TYPE}!="btrfs", GOTO="btrfs_end"
> >
> > # let the kernel know about this btrfs filesystem, and check if it is 
> > complete
> > IMPORT{builtin}="btrfs ready $devnode"
> >
> > # mark the device as not ready to be used by the system
> > ENV{ID_BTRFS_READY}=="0", ENV{SYSTEMD_READY}="0"
> >
> > LABEL="btrfs_end"
> 
> Yep.
> https://lists.freedesktop.org/archives/systemd-commits/2012-September/002503.html
> 
> The problem is that with rootflags=degraded it still indefinitely
> hangs. And even without the degraded option, I don't think the
> indefinite hang waiting for missing devices is the best way to find
> out there's been device failures. I think it's better to fail to
> mount, and end up at a dracut shell.

I figure it would be OK to merge a patch that makes the udev rules
above set SYSTEMD_READY immediately if the device popped up in case
some new kernel command line option is set.

Hooking up rootflags=degraded with this is unlikely to work I fear, as
by the time the udev rules run we have no idea yet what systemd wants
to make from the device in the end. That means knowing this early the
fact that system wants to mount it as root disk with some specific
mount options is not really sensible in the design...

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] [Solved] How to mount NFS prior to start postgresql from this volume

2016-07-05 Thread Lennart Poettering
On Mon, 04.07.16 09:40, wolfgang.wag...@riwa-gis.de 
(wolfgang.wag...@riwa-gis.de) wrote:

> >-Ursprüngliche Nachricht-
> >Von: Lennart Poettering [mailto:lenn...@poettering.net]
> >Betreff: Re: [systemd-devel] How to mount NFS prior to start postgresql from 
> >this volume
> >
> >Normally, if you want a service to run only after all NFS mounts are in 
> >place, add an ordering dependency towards remote-fs.target to it. 
> >Specifically: add a drop-in file
> >/etc/systemd/system/postgresql@.service.d/50-nfs.conf and write into it:
> >
> > 
> > [Unit]
> > After=remote-fs.target
> > 
> 
> 
> Thank You Lennart,
> 
> your tip was the solution for my problem.
> Now all works as expected.
> Only one question remains: I do not understand, why the "@" in the
> directory-name is necessary or what it does.

The "@" in the name indicates a templated unit. Templated units allow
you to write a single unit file that can be instantiated multiple
times. Not sure how precisely your postgresql packages make use of
this though.

A common example for this is getty@.service (the linux login prompt
thingy) which is the template that gets instantiated multiple times
for each tty the prompt is shown, and thus becomes getty@tty1.service,
getty@tty2.service and so on. See systemd.unit(5) for more information
about templates and instances of them.

By using drop-ins you may either extend the config of all instances of
a template, or just of one specific instance, by using the drop-in dir
/etc/systemd/system/foo@.service.d/ or
/etc/systemd/system/foo@bar.service.d/. The former applies to all
instances (as the instance part is left empty), and the latter only to
the instance "bar" of it.

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] How to set a limit for mounting roofs?

2016-07-05 Thread Chris Murphy
On Tue, Jul 5, 2016 at 12:45 PM, Chris Murphy  wrote:
> OK it must be this.
>
> :/# cat /usr/lib/udev/rules.d/64-btrfs.rules
> # do not edit this file, it will be overwritten on update
>
> SUBSYSTEM!="block", GOTO="btrfs_end"
> ACTION=="remove", GOTO="btrfs_end"
> ENV{ID_FS_TYPE}!="btrfs", GOTO="btrfs_end"
>
> # let the kernel know about this btrfs filesystem, and check if it is complete
> IMPORT{builtin}="btrfs ready $devnode"
>
> # mark the device as not ready to be used by the system
> ENV{ID_BTRFS_READY}=="0", ENV{SYSTEMD_READY}="0"
>
> LABEL="btrfs_end"

Yep.
https://lists.freedesktop.org/archives/systemd-commits/2012-September/002503.html

The problem is that with rootflags=degraded it still indefinitely
hangs. And even without the degraded option, I don't think the
indefinite hang waiting for missing devices is the best way to find
out there's been device failures. I think it's better to fail to
mount, and end up at a dracut shell.

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


Re: [systemd-devel] How to set a limit for mounting roofs?

2016-07-05 Thread Chris Murphy
OK it must be this.

:/# cat /usr/lib/udev/rules.d/64-btrfs.rules
# do not edit this file, it will be overwritten on update

SUBSYSTEM!="block", GOTO="btrfs_end"
ACTION=="remove", GOTO="btrfs_end"
ENV{ID_FS_TYPE}!="btrfs", GOTO="btrfs_end"

# let the kernel know about this btrfs filesystem, and check if it is complete
IMPORT{builtin}="btrfs ready $devnode"

# mark the device as not ready to be used by the system
ENV{ID_BTRFS_READY}=="0", ENV{SYSTEMD_READY}="0"

LABEL="btrfs_end"





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


Re: [systemd-devel] How to set a limit for mounting roofs?

2016-07-05 Thread Chris Murphy
On Tue, Jul 5, 2016 at 10:53 AM, Chris Murphy  wrote:

> It seems like this dracut doesn't understand rd.timeout.

OK now on Fedora Rawhide and rd.timeout=30 appears to work. The
failure is the same, systemd is waiting for /dev/vda2 for an unknown
reason, it doesn't even attempt to mount it so this is not (yet) a
mount failure.

And journalctl is more revealing...but I'm still lost.
https://drive.google.com/open?id=0B_2Asp8DGjJ9dE1MOWlXbjYyeVE

[4.510767] localhost.localdomain systemd[1]: dev-vda1.device:
Changed dead -> plugged
[4.510995] localhost.localdomain systemd[1]:
sys-devices-pci:00-:00:09.0-virtio2-block-vda-vda1.device:
Changed dead -> plugged

That never happens for vda2.

[4.602049] localhost.localdomain systemd-udevd[205]: worker [226] exited
[   63.212453] localhost.localdomain systemd[1]: dev-vda2.device: Job
dev-vda2.device/start timed out.
[   63.213227] localhost.localdomain systemd[1]: dev-vda2.device: Job
dev-vda2.device/start finished, result=timeout
[   63.213904] localhost.localdomain systemd[1]: Timed out waiting for
device dev-vda2.device.

It goes direct from udevd stuff, long wait with nothing happening,
then time out. I wonder if this is a problem in 64-btrfs.rules just
because there is a missing device. I thought root=/dev/vda2 would work
around the problem where btrfs udev rules does not instantiate the
Btrfs volume UUID if there is a missing device; and now I wonder if
this has been misunderstood all along.

In the shell

:/# blkid
/dev/sr0: UUID="2016-07-04-07-03-49-00"
LABEL="Fedora-S-dvd-x86_64-rawh" TYPE="iso9660" PTUUID="6c9a3e8e"
PTTYPE="dos"
/dev/vda1: UUID="b061db37-3ef5-4b5c-aef0-bbaa360f7788" TYPE="ext4"
PARTUUID="6cd85e0f-01"
/dev/vda2: LABEL="fedora" UUID="488791ba-5796-4653-a3da-62c36fc2067b"
UUID_SUB="61d57d89-4299-4d84-8e78-c3833ac297f3" TYPE="btrfs"
PARTUUID="6cd85e0f-02"
:/#

blkid very clearly sees both vda2 and the volume UUID. I can manually
mount this volume from this same shell but somehow between systemd and
udev, they can't figure it out because they're waiting for something
to happen before even trying to mount. What are they waiting for, the
missing device to show up? Maybe that's the problem, degraded boot of
Btrfs is simply not supported at all?



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


Re: [systemd-devel] How to set a limit for mounting roofs?

2016-07-05 Thread Chris Murphy
New console log.
Command line: BOOT_IMAGE=/vmlinuz-3.10.0-327.22.2.el7.x86_64
root=/dev/vda2 ro rootflags=subvol=root,degraded vconsole.keymap=us
crashkernel=auto vconsole.font=latarcyrheb-sun16 LANG=en_US.UTF-8
rd.timeout=30 rd.debug rd.udev.debug systemd.log_level=debug
systemd.log_target=console console=ttyS0,38400

It seems like this dracut doesn't understand rd.timeout. And even with
rd.shell it doesn't drop to a shell. I don't see any attempt to even
mount vda2 so I don't know what the job is waiting for. If the mount
were to explicitly fail not finding vda2 or the root subvolume or
unable to mount degraded, that presumably would trigger rd.shell. But
that doesn't happen, just waiting.

https://drive.google.com/open?id=0B_2Asp8DGjJ9WW9FMzIwNGJQSGc


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


Re: [systemd-devel] How to set a limit for mounting roofs?

2016-07-05 Thread Chris Murphy
pre-mount:/# cat /run/systemd/generator/dev-vda2.device.d/timeout.conf
[Unit]
JobTimeoutSec=0


This is virsh console output during boot:
https://drive.google.com/open?id=0B_2Asp8DGjJ9RlN1cGJTTEtHcjg

Here is journalctl -b -o short-monotonic output from the pre-mount
shell using Command line:
BOOT_IMAGE=/vmlinuz-3.10.0-327.22.2.el7.x86_64 root=/dev/vda2 ro
rootflags=subvol=root,degraded vconsole.keymap=us crashkernel=auto
vconsole.font=latarcyrheb-sun16 rhgb quiet LANG=en_US.UTF-8
systemd.log_level=debug rd.udev.debug rd.debug
systemd.log_target=console console=ttyS0,38400 rd.break=pre-mount

https://drive.google.com/open?id=0B_2Asp8DGjJ9OThvS2Q3X3pWT3c


What I'm getting from the journal is...

[2.939557] localhost.localdomain kernel: virtio-pci :00:05.0:
irq 27 for MSI/MSI-X
[2.939595] localhost.localdomain kernel: virtio-pci :00:05.0:
irq 28 for MSI/MSI-X
[2.939849] localhost.localdomain kernel:  vda: vda1 vda2

OK so the kernel sees the drive and the partitions.

[3.043274] localhost.localdomain kernel: Btrfs loaded
[3.043836] localhost.localdomain kernel: BTRFS: device label
centos devid 1 transid 55 /dev/vda2

It sees the file system on /dev/vda2 (raid1, missing device vdb1)

But then I hit pre-mount so I don't actually find out why it won't
mount. If there were a problem with degraded mounts, the mount should
explicitly fail, and then systemd would drop to a shell if rd.shell is
used. But it doesn't. It just hangs. So the mount isn't hard failing,
it's like some kind of soft fail where systemd just waits for some
reason.


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


Re: [systemd-devel] How to set a limit for mounting roofs?

2016-07-05 Thread Chris Murphy
On Mon, Jul 4, 2016 at 9:24 PM, Andrei Borzenkov  wrote:
> 04.07.2016 21:32, Chris Murphy пишет:
>> I have a system where I get an indefinite
>>
>> "A start job is running for dev-vda2.device (xmin ys / no limit)"
>>
>> Is there a boot parameter to use to change the no limit to have a
>> limit? rd.timeout does nothing.
>
> It should. Use rd.break and examine unit configuration (systemctl show
> dev-vda2.device) as well as /run/systemd/system/dev-vda1.device.d.
> dracut is using infinite timeout by default indeed.

pre-mount:/# systemctl status dev-vda2.device
Got unexpected auxiliary data with level=1 and type=2
Accepted new private connection.
Got unexpected auxiliary data with level=1 and type=2
Got unexpected auxiliary data with level=1 and type=2
Got message type=method_call sender=n/a
destination=org.freedesktop.systemd1
object=/org/freedesktop/systemd1/unit/dev_2dvda2_2edevice
interface=org.freedesktop.DBus.Properties member=GetAll cookie=1
reply_cookie=0 error=n/a
Sent message type=method_return sender=n/a destination=n/a object=n/a
interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a
● dev-vda2.device
   Loaded: loaded
  Drop-In: /run/systemd/generator/dev-vda2.device.d
   └─timeout.conf
   Active: inactive (dead)
Got disconnect on private connection.

pre-mount:/# ls -la /run/systemd/system/
total 0
drwxr-xr-x 2 root 0  40 Jul  5 15:36 .
drwxr-xr-x 7 root 0 180 Jul  5 15:36 ..


This is CentOS 7.2.
pre-mount:/# systemctl --version
systemd 219
+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID +ELFUTILS
+KMOD +IDN

Once I get a better idea what's going on here, I'll check it with
Fedora Rawhide so any bugs/rfe's are based on stuff closer to upstream
versions.


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


Re: [systemd-devel] Standardizing names for graphical session units

2016-07-05 Thread Simon McVittie
On 04/07/16 21:01, Martin Pitt wrote:
> A session type like "GNOME" or "KDE" then defines which top-level
> servcies it wants.

Could this be done by having the .desktop file in /usr/share/xsessions
or /usr/share/wayland-sessions start an appropriate systemd user unit
directly, and wait for it to terminate?

> Ideally we could hook the startup of graphical.slice into the system
> logind scope; but as the user systemd does not "see" the
> systemd users, this isn't possible. So for now pretty much the only
> way is to go via an /X11/xinit/xinitrc.d (Fedora) or
> /etc/X11/Xsession.d/ (Debian) script

These scripts are a necessary evil for X11, but in the Wayland future,
the plan (at least in GNOME) seems to be for them not to be replicated;
if gdm is told to launch a session from /usr/share/wayland-sessions, it
doesn't execute X11 startup script snippets. (It does have a
gdm-specific way to set environment variables, and I'm planning to
extend pam_env to support systemd-style .d drop-in directories to
generalize that.) A more declarative session startup seems like a better
session startup.

I'm not sure what you do for Mir in Ubuntu, but I'd advocate a similar
approach - sourcing a couple of dozen Turing-complete shell script
fragments during session startup makes it rather difficult to reason about.

S

-- 
Simon McVittie
Collabora Ltd. 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel