Re: [systemd-devel] How to remove *~ journal files?

[Andrei Borzenkov]

On 14.08.2015 20:41, Lennart Poettering wrote:


BTW, if you keep collecting these files, then this is usually an
indication that journald is flaky or you keep rebooting the machine
too often in a "hard" way.


Yes, this is the case. This system requires hard power off rather more 
often than I wished.


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

Re: [systemd-devel] Troubleshooting Failed Nspawn Starts

[Rich Freeman]

On Fri, Aug 14, 2015 at 1:30 PM, Lennart Poettering
 wrote:
> On Mon, 10.08.15 08:03, Rich Freeman (r-syst...@thefreemanclan.net) wrote:
>
> We have watchdog (see WatchdogSec= documentation in
> systemd.service(5)) support in all our long-running daemons, and PID 1
> will kill the service and generate a backtrace for them if they don't
> send a watchdog message often enough. So actually we should be pretty
> good here...

Thanks.  In this case I'm not sure if it is needed more for nspawn
itself, or for systemd (which probably won't work unless nspawn
supports watchdog), or for journald/etc.

>
>> Example of a frozen container:
>>
>> systemctl status mariadb-contain
>> ● mariadb-contain.service - mariadb container
>>Loaded: loaded (/etc/systemd/system/mariadb-contain.service;
>> enabled; vendor preset: enabled)
>>Active: active (running) since Mon 2015-08-10 07:21:48 EDT; 37min ago
>>  Docs: man:systemd-nspawn(1)
>>  Main PID: 1033 (systemd-nspawn)
>>Status: "Container running."
>>CGroup: /system.slice/mariadb-contain.service
>>├─1033 /usr/bin/systemd-nspawn --quiet --keep-unit --boot
>> --link-journal=guest --directory=/sstorage3/cont...
>>├─1044 /usr/lib/systemd/systemd
>>└─system.slice
>>  ├─systemd-journald.service
>>  │ └─1407 /usr/lib/systemd/systemd-journald
>>  └─systemd-journal-flush.service
>>└─1340 /usr/bin/journalctl --flush
>
> Hmm, this is really weird... Would be good to get a backtrac of both
> journald and journalctl here. Note that journald has a much higher PID
> that journalctl though, which indicates that it might have gotten
> restarted by systemd already...

I'll look to get one.

>
> journalctl --flush actually pretty much only sends SIGUSR1 to
> journald, but does this through PID1's bus APIs... It then waits for a
> file in /run/systemd/journal/flushed to appear... For some reason that
> doesn't work here... Weird...

I'm actually wondering if it is some kind of dbus api issue.  I don't
have anything in this email but I seem to recall seeing some error in
a situation like this that mentioned dbus.

>
> Anyway, before tracking this down further, could you update to a more
> recent systemd version?

That's fair to ask.  I'll see about doing just that.  Perhaps it will
resolve the issue as a bonus.  I've been seeing this for a while
though.

The other issue I see sometimes is restarting an nspawn container with
bridged ethernet and having it fail with an error that the interface
is already in use.  After I update I'll see if I can get more info on
that (though in that case everything terminates).

--
Rich
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Who has rights to override/ignore inhibitors?

[Jayson Willson]

Hello. I have realized, that my user (groups: 
tty,disk,mail,news,dialout,voice,sudo,audio,www-data,video,plugdev,users,mlocate,kvm,vboxusers,libvirt) 
can ignore inhibitors (such as root being logged in) using "systemctl 
suspend -i" without password prompt (though su, sudo and polkit do 
require password).
Could you please tell me, which users can ignore inhibitors, and what 
should be changed to change such behaviour? Thank you.

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

Re: [systemd-devel] possible kernel crash on bootctl install, can anyone confirm?

[Michał Zegan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

May be, I asked systemd folks to confirm because this may or may not
be specific to something systemd does internally when modifying them.
I didn't get anything on efibootmgr, and I also didn't try again to
use bootctl install, I just created entries with efibootmgr.

W dniu 2015-08-14 o 19:45, Mantas Mikulėnas pisze:
> On Fri, Aug 14, 2015 at 8:42 PM, Michał Zegan 
> mailto:webczat_...@poczta.onet.pl>>
> wrote:
> 
> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
> 
> Hello.
> 
> I was trying to install archlinux with linux 4.1, systemd-224 on
> the uefi machine. At the end of system installation, I issued
> bootctl install command from within chroot, but the command has
> failed because I did not have access to efi variables. After that,
> I have done: mount -t efivarfs efivarfs
> /mnt/sys/firmware/efi/efivars (the mountpoint path may be wrong but
> you get the idea) And, after the next bootctl install, the system
> froze. I am blind and didn't ask anyone what happened, but I
> believe that the kernel panicked. Is this related to mounting
> efivarfs two times and modifying variables, or what? I do not have
> any vm to test it on, well. Can anyone confirm that something like
> that happens either normally or when mounting efivarfs twice?
> 
> 
> This might be a bug in 4.1's EFI variables handling... A few people
> in #archlinux, including myself, have noticed crashes if the
> efivars are accessed after hibernate & resume (on first try,
> efibootmgr segfaults; on second try, the kernel panics). I haven't
> gotten around to reporting it yet.
> 
> -- Mantas Mikulėnas mailto:graw...@gmail.com>>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJVzi30AAoJEHb1CzgxXKwYhsgP/34RqtNYRJkQ3KKbvo9UXIZh
uzvaGQMW31GBHONxcwJRltk9aRYa3gkqJBNcpZTKXgH/jsjc997fMR7nXlKyZ6gX
8AbGDTmutxXM6/LsLzSO4KXCDBOXYgG8Gfzai9U+i08t8oktHeMTgFpZyq/Jv2jq
Y4HhK9PiqdInNt+voteUzR0Q6DpmndLqQDjpJrApxKz59wN5wQYejm4+CoqcXOMs
bAT6nbKC2oDFs9SOVP1qVNx5oY/jb07gQfMLlTe3wu06/6EfEK4G5Pzj20JVWJtf
sTXXXyx7Fm/ykhLi3Yw6yypBnneQh9a35SLOCCDScVWshS+bc8hiGJap4kQV0mnh
utTuRXe6ns9KlOkuI56+1KMohw7FWcC46d/V2R6wiZKT2fTEfiAVIJlR5NGctrqw
vkZOc7Pa4SQhn/a/V26R51RirpeWT0CHvib5BIFpd57wgeTUQo+AH68DdStnLj/V
EPE/tbetlduIvLyDWVRpFMVmd826Jf0eNmZL5VnqVtHPV71b/0qu6R4anDxZ5EtQ
nJ/3WenYINXUanVj5cepz2Ta/e9Kpm/abTWE/l/yC+rE42s8x6aQYd4BYOqp7K1m
7ElALMIbsHckjQGizXB5gB82HPHBkbHIXw+XA47QwV9Bv2DmB4E4asiBIYZRle1i
ZfxfwaIl8eY7EZoG/9YS
=M2UL
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] network configuration

[Michał Zegan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Actually what is a procedure for more complicated network
configuration, where you do not have something in networkd?

W dniu 2015-08-14 o 19:33, Lennart Poettering pisze:
> On Sun, 09.08.15 18:23, Michał Zegan (webczat_...@poczta.onet.pl)
> wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>> 
>> Actually everything should be settable that can be done with
>> ip-route and ip-address and stuff... And ip-rule, by the way. 
>> But, no. Source= parameter in route sections is for source based 
>> routing without adding rules, not to set a preferred source ip 
>> address. Checked/tested.
> 
> We generally try to avoid exposing every possible option, but only
> the ones that people really use and make sense to support. What
> you suggest here probably does make sense to add, hence please file
> an RFE bug in github, and we'll eventually add it. Even better:
> send a patch!
> 
> Thanks,
> 
> Lennart
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJVzipJAAoJEHb1CzgxXKwYdtMP/3FsU/o5/GWiWZ7KGPgJMgC5
lAd2O5NjdCIXjwxH6yaCvrDrKGMPVqRUWpqusTMxhgXSId+7MkFuGseJG4+mEYY5
KtxrqIIzZDsrhAra6FduzBifiTnD/N51+uds1r5g4yU0oQDNb5opKjO6uClwpo6K
Eth2ebTFMqe2ijGMfScEm02P5l9VvWY8u7pdAXqffjVNlLkLAO+8VdWFLljJhjqc
SGEJhX42E9+67x6vS7tYigFEcM1H6PftvOeayAlK/A9NVcRSHo9YnrRFW+Tcig2F
lur9dP2/ZVW06DpJWxx4kDvOuKqw5hnM/O+0Xck6mCauGgF8yEoemgsoRWjEOCBB
jsHEdlCLWoAPgDQQ6ywwEZ25e2TDkA/53hfrg8lA4o5Hn0oYS+sy6C39v64uJVgD
S+8+CRQjzjtGF2Xxu6x3GTRvlhdAKb/jSIC6qCQ7AaHzOqN6yZQ7Bo8rp1mu/eCx
jb+JR4P/ext+PX93Q91YqOwmv6sqnCrxLwdUn0qHRyyr0OzLpw7EDz6fIhZkg494
MifKvgCGqwA6Q8u9kZFwOLgyemkQ0fa6A+33YqcmgaUmKcFsrXjGVWeeL6iohlCV
Iua85N2Ogl/LfeE5NWp+kFP6e1DgLFO2J4/KVdF3mYfzkNvNCHFrCa3AQYHBAJDp
qQ7T8ihJcM3EAmLDWypm
=YHEv
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] possible kernel crash on bootctl install, can anyone confirm?

[Mantas Mikulėnas]

On Fri, Aug 14, 2015 at 8:42 PM, Michał Zegan 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello.
>
> I was trying to install archlinux with linux 4.1, systemd-224 on the
> uefi machine.
> At the end of system installation, I issued bootctl install command
> from within chroot, but the command has failed because I did not have
> access to efi variables.
> After that, I have done:
> mount -t efivarfs efivarfs /mnt/sys/firmware/efi/efivars (the
> mountpoint path may be wrong but you get the idea)
> And, after the next bootctl install, the system froze. I am blind and
> didn't ask anyone what happened, but I believe that the kernel panicked.
> Is this related to mounting efivarfs two times and modifying
> variables, or what? I do not have any vm to test it on, well. Can
> anyone confirm that something like that happens either normally or
> when mounting efivarfs twice?
>

This might be a bug in 4.1's EFI variables handling... A few people in
#archlinux, including myself, have noticed crashes if the efivars are
accessed after hibernate & resume (on first try, efibootmgr segfaults; on
second try, the kernel panics). I haven't gotten around to reporting it yet.

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

Re: [systemd-devel] possible kernel crash on bootctl install, can anyone confirm?

[Lennart Poettering]

On Fri, 14.08.15 19:42, Michał Zegan (webczat_...@poczta.onet.pl) wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hello.
> 
> I was trying to install archlinux with linux 4.1, systemd-224 on the
> uefi machine.
> At the end of system installation, I issued bootctl install command
> from within chroot, but the command has failed because I did not have
> access to efi variables.
> After that, I have done:
> mount -t efivarfs efivarfs /mnt/sys/firmware/efi/efivars (the
> mountpoint path may be wrong but you get the idea)
> And, after the next bootctl install, the system froze. I am blind and
> didn't ask anyone what happened, but I believe that the kernel panicked.
> Is this related to mounting efivarfs two times and modifying
> variables, or what? I do not have any vm to test it on, well. Can
> anyone confirm that something like that happens either normally or
> when mounting efivarfs twice?

No, that should work fine. You can mount the fs as many times as you
wish, and that should be without issues. If it is, that'd be a kernel
bug, and needs to be fixed there.

Note that systemd mounts efivarfs automatically to
/sys/firmware/efi/efivars anyway, so there should be no reason to ever
mount int manually?

Lennart

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

[systemd-devel] possible kernel crash on bootctl install, can anyone confirm?

[Michał Zegan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello.

I was trying to install archlinux with linux 4.1, systemd-224 on the
uefi machine.
At the end of system installation, I issued bootctl install command
from within chroot, but the command has failed because I did not have
access to efi variables.
After that, I have done:
mount -t efivarfs efivarfs /mnt/sys/firmware/efi/efivars (the
mountpoint path may be wrong but you get the idea)
And, after the next bootctl install, the system froze. I am blind and
didn't ask anyone what happened, but I believe that the kernel panicked.
Is this related to mounting efivarfs two times and modifying
variables, or what? I do not have any vm to test it on, well. Can
anyone confirm that something like that happens either normally or
when mounting efivarfs twice?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJVziiQAAoJEHb1CzgxXKwY9MkP/0lCTt80maAOrDpIaidioNC6
i+Iio0IzKEe4JV1hEUl7ZDKZdG0d44JMTNBgoOhKCRucXmWUsCuG52B8CukqDKoj
/mWbkVB2rcoejMKGBdly9uaSBehtOeneouDP+FN6erckvGzS1y643n49ZnSv1vrr
Q6nY/DpJyNfmMwv+dWYB3CKTXASRY6GTbLUrwOd39GDZNRexgAIvduClc89qeAu4
sPWgs1zbaHdJPDtFxkrDazHTasRq1tDUTgFYZM0TC9aKsTBoLZQ06XjlwdieZ+ZN
L/AE51xDfA2t/xSE0ImXJy9gYOglJiRV1rvJdAiQKtwBSHe9JrOhYDH6p0p80T14
sHTML3V/PMUlzrAfIcQ6AhBtouLuNBxEV9YzF4D5Mf4e3A7p8pJZec8BW+ey4Yvq
0Q0rG8W3VlYM0/ySP7mI1UAJPrslNig0OFEod2ABri3zP1k0IEQ+zIFCf+F2PrKE
Ps0L3+wuQeyNkGfwP1dNECUyqj5XWKgmqPR4xSD5vuneJJMiRKQj9YFPV+ajkgjD
y0FPQunB09zq4fziTrz0bT3cqPgPiyRvodLuCUvQ3LHUALP8UHO0ONVQ0joYuFCH
9U1lzsktkLtDJFfINAOkX5dV0jO/mtDFqiFwv8/2REe/FU0ncLqJfxymWhs53iXj
NGKXXSykQ7dW6s1J7BBy
=M3na
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to remove *~ journal files?

[Lennart Poettering]

On Sun, 09.08.15 09:57, Andrei Borzenkov (arvidj...@gmail.com) wrote:

> More than half of all files here are *~ files:
> 
> bor@opensuse:~/src/systemd> ls -1 
> /var/log/journal/40527be2480f8cf60f4e8d4b06b0/*~ | wc -l
> 85
> bor@opensuse:~/src/systemd> ls -1 
> /var/log/journal/40527be2480f8cf60f4e8d4b06b0/* | wc -l
> 127
> 
> If I understand it correctly they are corrupted files. Should not they
> have been deleted? What is the correct procedure to remove them?

As Mantas already suggested: these are *not* corrupted files. These
are simply files which journald found on startup where the "dirty" bit
in the header was not unset on last access. i.e. files that weren't
closed cleanly, maybe because the system was shutdown forcibly without
terminating journald cleanly, or because journald died or similar.

journalctl will read those files just fine usually, only the final
bits might not have been synced to disk fully, and journalctl tries
hard to read as much as it can still.

We simple move these files away (and mark them with the trailing ~),
to avoid breaking them by writing further data to it. Instead we start
new files.

Hence: do not delete them, they are still useful. journald will clean
them up eventually, like any other journal files. You can use
"journalctl --vacuum-size=" or "journactl --vacuum-time=" in order to
do one-time cleaning. But note that this will not distuingish journal
files with or without the "~", it strictly deletes the oldest files
regardless if "dirty" or not "dirty".

BTW, if you keep collecting these files, then this is usually an
indication that journald is flaky or you keep rebooting the machine
too often in a "hard" way. If journald works fine and you always
shutdown cleanly you should never get any of these at all.

Lennart

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

Re: [systemd-devel] network configuration

[Lennart Poettering]

On Sun, 09.08.15 18:23, Michał Zegan (webczat_...@poczta.onet.pl) wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Actually everything should be settable that can be done with ip-route
> and ip-address and stuff...
> And ip-rule, by the way.
> But, no. Source= parameter in route sections is for source based
> routing without adding rules, not to set a preferred source ip
> address. Checked/tested.

We generally try to avoid exposing every possible option, but only the
ones that people really use and make sense to support. What you
suggest here probably does make sense to add, hence please file an RFE
bug in github, and we'll eventually add it. Even better: send a patch!

Thanks,

Lennart

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

Re: [systemd-devel] Ignoring default gateway when configuring via dhcp

[Lennart Poettering]

On Mon, 10.08.15 11:47, Jetchko Jekov (jetchko.je...@gmail.com) wrote:

> Greetings,
> 
> I am investigating a possibility for using systemd-networkd for
> networking setup but I am not able to figure out how to configure
> networkd to skip installing a default gateway even if dhcp server
> offers one.
> Just for clarification, I guess UseRoutes=false can be used if there
> is only default gateway offered, but in case when dhcp server provides
> classless static routes option (RFC3442) with additional routes, the
> default gateway is specified there too and I cant find a way to ignore
> it.

Hmm, so let me get this right: if both the default route and the
rfc3442 routes are contained in the DHCP lease, then you want us to
optionally ignore the default route, but keep the rfc3442 routes?

What#s the usecase for this? Sounds quite specific too me, and not
useful in the general case, no?

Lennart

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

Re: [systemd-devel] Troubleshooting Failed Nspawn Starts

[Lennart Poettering]

On Mon, 10.08.15 08:03, Rich Freeman (r-syst...@thefreemanclan.net) wrote:

> Occassionally I'll have nspawn containers that freeze up when they're
> loading.  What is the best way to troubleshoot these and get useful
> info to devs?

Well, not sure what "freeze" means here... I'd always start by getting
a stack trace of the processes tha hang. Try the "pstack" tool on the
processes to get a backtrace.

> This is on systemd-218, on Gentoo.

Upstream we try to focus on very recent systemd only...

> Also, is there any way to detect these freezes, perhaps getting the
> service launching it to at least fail?  Short of installing nagios/etc
> something like this is hard to spot right now.

We have watchdog (see WatchdogSec= documentation in
systemd.service(5)) support in all our long-running daemons, and PID 1
will kill the service and generate a backtrace for them if they don't
send a watchdog message often enough. So actually we should be pretty
good here...

> Example of a frozen container:
> 
> systemctl status mariadb-contain
> ● mariadb-contain.service - mariadb container
>Loaded: loaded (/etc/systemd/system/mariadb-contain.service;
> enabled; vendor preset: enabled)
>Active: active (running) since Mon 2015-08-10 07:21:48 EDT; 37min ago
>  Docs: man:systemd-nspawn(1)
>  Main PID: 1033 (systemd-nspawn)
>Status: "Container running."
>CGroup: /system.slice/mariadb-contain.service
>├─1033 /usr/bin/systemd-nspawn --quiet --keep-unit --boot
> --link-journal=guest --directory=/sstorage3/cont...
>├─1044 /usr/lib/systemd/systemd
>└─system.slice
>  ├─systemd-journald.service
>  │ └─1407 /usr/lib/systemd/systemd-journald
>  └─systemd-journal-flush.service
>└─1340 /usr/bin/journalctl --flush

Hmm, this is really weird... Would be good to get a backtrac of both
journald and journalctl here. Note that journald has a much higher PID
that journalctl though, which indicates that it might have gotten
restarted by systemd already...

journalctl --flush actually pretty much only sends SIGUSR1 to
journald, but does this through PID1's bus APIs... It then waits for a
file in /run/systemd/journal/flushed to appear... For some reason that
doesn't work here... Weird...

Anyway, before tracking this down further, could you update to a more
recent systemd version?

Lennart

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

Re: [systemd-devel] Journal log rotation notification

[Lennart Poettering]

On Fri, 14.08.15 13:20, giulix (giulio.marti...@gmail.com) wrote:

> Hello,
> 
> I have a process that reads from the journald log file. It gets a
> notification from inotify that something's changed, opens the journal, skims
> through it for messages it's interested in, does its stuff and closes the
> journal file 
> (http://www.giulix.it/content/extracting-data-systemd-journal-programmatically).
> When the journal log file is rotated, the process stops to do its job. It
> is, of course, because it never realizes the file it's waiting on for
> notifications via inotify has changed.
> I have uselessly tried to implement some mechanism to have my process
> restarted when the journal file changes, but it seems that nothing is
> available from systemd or journald to notify a process that journald is
> switching to a new output file.
> 
> Is there anything that I have missed?

As Mantas already mentioned: sd-journal.h already provides you with a
way to get notifications about journal changes, and it does handle
rotation properly. It internally uses inotify on the directories to
ensure it can track this all nicely. I'd always recommend using the
sd-journal.h API for watching the journal rather than watching things
on your own, since then it's our upstream duty to fix things if the
watching should be buggy...

Lennart

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

Re: [systemd-devel] udev-buildin-net_id.c hotplug slot with SRIOV

[Keller, Jacob E]

On Fri, 2015-08-14 at 06:29 +0300, Andrei Borzenkov wrote:
> 
> On 14.08.2015 02:39, Keller, Jacob E wrote:
> > Hello,
> > 
> > I discussed this a while ago, but I have found that the hotplug
> > slot
> > names for ethernet devices gets confused when SRIOV is used.
> > 
> > Basically:
> > 
> > I have a device plugged into a hotplug slot, and it gets
> > 
> > enps for its PCI path name.
> > 
> > For the slot, it gets
> > 
> > ens
> > 
> > Example:
> > 
> > enp5s0
> > 
> > ens1
> > 
> > However, this device has SR-IOV functionality, and it creates new
> > VFs
> > which appear at different functional bus:slot.func values.
> > 
> > In this device's case, as long as the particular layout for VFs
> > puts
> > these in only functions 1-7 then I get
> > 
> > ens1f1
> > ens1f2
> > ens1f3
> > 
> > that is all great. However, devices are free to layout their SR
> > -IOVs
> > into PCI cfg space at separate slots, ie: enp5s1f0 etc.
> > 
> > The issue comes up because *now* the hotplug slot functionality no
> > longer works: for some of the VFs, I get devices named above, others
> > now get
> > 
> > enp5s1f0
> > 
> > and so forth.
> > 
> > This is very confusing to the user as they use this device and
> > don't
> > understand why it gets alternating user schemes.
> > 
> > I believe the error results from line 248 of udev-builtin-net_id.c
> > 
> > In this case, we check if we're a hotplug slot by checking if the
> > bus
> > *and* slot are both equivalent. However, on my system all the
> > hotplug
> > slots are always only at a specific bus, and not at a non-zero
> > slot.
> > 
> 
> Could you show lspci -t with VF created?

 \-[:00]-+-00.0
 +-01.0-[01-03]00.0-[02-03]08.0-[03]--+-00.0
 |+-00.3
 |\-00.4
 +-01.1-[04-05]--+-00.0
 |   +-00.1
 |   +-00.2
 |   \-00.3
 +-02.0-[06-09]00.0-[07-09]--+-08.0-[08]--+-00.0
 |   |+-00.1
 |   |+-00.2
 |   |+-00.3
 |   |+-00.4
 |   |+-00.5
 |   |+-00.6
 |   |+-00.7
 |   |+-01.0
 |   |+-01.1
 |   |+-01.2
 |   |+-01.3
 |   |+-01.4
 |   |+-01.5
 |   |+-01.6
 |   |+-01.7
 |   |+-02.0
 |   |+-02.1
 |   |+-02.2
 |   |+-02.3
 |   |+-02.4
 |   |+-02.5
 |   |+-02.6
 |   |+-02.7
 |   |+-03.0
 |   |+-03.1
 |   |+-03.2
 |   |+-03.3
 |   |+-03.4
 |   |+-03.5
 |   |+-03.6
 |   |+-03.7
 |   |+-04.0
 |   |+-04.1
 |   |+-04.2
 |   |+-04.3
 |   |+-04.4
 |   |+-04.5
 |   |+-04.6
 |   |+-04.7
 |   |+-05.0
 |   |+-05.1
 |   |+-05.2
 |   |+-05.3
 |   |+-05.4
 |   |+-05.5
 |

[systemd-devel] Regression: 'jounalctl -f -t unmatched' does not block

[Stef Walter]

Hi,

The Cockpit integration test suite caught a recent regression in
systemd. Using journalctl -f to follow unmatched criteria is broken.
More details here:

https://bugzilla.redhat.com/show_bug.cgi?id=1253649

Here's a patch:

https://github.com/systemd/systemd/pull/958

Stef



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Journal log rotation notification

[giulix]

Mantas,

I do not want to reimplement all the logic myself, I just want to get 
journal entries directly at the source. The syscall you listed will do 
nicely, thank you, provided it supplies the right inode everytime my 
process is awakened by inotify. I will test it in the next hours/days.


Thanks again for this precious insight.

giulix

On 08/14/2015 01:56 PM, Mantas Mikulėnas wrote:
On Fri, Aug 14, 2015 at 2:20 PM, giulix > wrote:


Hello,

I have a process that reads from the journald log file. It gets a
notification from inotify that something's changed, opens the
journal, skims through it for messages it's interested in, does
its stuff and closes the journal file

(http://www.giulix.it/content/extracting-data-systemd-journal-programmatically).
When the journal log file is rotated, the process stops to do its
job. It is, of course, because it never realizes the file it's
waiting on for notifications via inotify has changed.
I have uselessly tried to implement some mechanism to have my
process restarted when the journal file changes, but it seems that
nothing is available from systemd or journald to notify a process
that journald is switching to a new output file.


There is no need for a signal – inotify can inform you about renames 
as well.


But, you shouldn't reimplement the entire logic yourself. (There's 
more to it, like separate systemd or user journals) *Instead, call 
sd_journal_get_fd(3) and let libsystemd do the monitoring.*


--
Mantas Mikulėnas mailto:graw...@gmail.com>>


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

Re: [systemd-devel] Journal log rotation notification

[Mantas Mikulėnas]

On Fri, Aug 14, 2015 at 2:20 PM, giulix  wrote:

> Hello,
>
> I have a process that reads from the journald log file. It gets a
> notification from inotify that something's changed, opens the journal,
> skims through it for messages it's interested in, does its stuff and closes
> the journal file (
> http://www.giulix.it/content/extracting-data-systemd-journal-programmatically
> ).
> When the journal log file is rotated, the process stops to do its job. It
> is, of course, because it never realizes the file it's waiting on for
> notifications via inotify has changed.
> I have uselessly tried to implement some mechanism to have my process
> restarted when the journal file changes, but it seems that nothing is
> available from systemd or journald to notify a process that journald is
> switching to a new output file.
>

There is no need for a signal – inotify can inform you about renames as
well.

But, you shouldn't reimplement the entire logic yourself. (There's more to
it, like separate systemd or user journals) *Instead, call
sd_journal_get_fd(3) and let libsystemd do the monitoring.*

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

[systemd-devel] Journal log rotation notification

[giulix]

Hello,

I have a process that reads from the journald log file. It gets a 
notification from inotify that something's changed, opens the journal, 
skims through it for messages it's interested in, does its stuff and 
closes the journal file 
(http://www.giulix.it/content/extracting-data-systemd-journal-programmatically).
When the journal log file is rotated, the process stops to do its job. 
It is, of course, because it never realizes the file it's waiting on for 
notifications via inotify has changed.
I have uselessly tried to implement some mechanism to have my process 
restarted when the journal file changes, but it seems that nothing is 
available from systemd or journald to notify a process that journald is 
switching to a new output file.


Is there anything that I have missed?

Thanks,

giulix
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Why is my docked idle laptop suspended?

[Lennart Poettering]

On Thu, 13.08.15 22:53, Michal Sojka (sojk...@fel.cvut.cz) wrote:

> Hi list,
> 
> I'm trying to figure out why is my laptop automatically suspended after
> being idle in a docking station. As far as I understand, logind should
> not suspend when the laptop is docked or external monitor is connected.
> 
> Below is the (partially filtered) system log of what happens before the
> suspend. Things start at 17:34:09 when my screensaver sets IdleHint. Few
> minutes later (17:37) something happens and the logind suspends the
> system. I don't expect that network manager, active at the same time,
> can cause this.
> 
> When looking at function manager_is_docked_or_external_displays(), when
> my system is docked, I should see "System is docked." message, but
> instead I see "External (1) displays connected." Can it be that the
> monitor powers down automatically and logind suspends the system because
> it is not aware of being docked?

Note that systemd will print "System is docked" only if there's an
actual "docking" state known, i.e. via some input device that is
connected to the hinge of your laptop. Most laptops don't expose
this. In that case we count external displays, and then you only see
the "External displays connected" message, instead.

Which version of systemd are you running?

Maybe some other usperspace service is triggering the suspend?

> 
> If yes, how can I make logind be aware of being docked?
> 
> Thank you.
> -Michal
> 
> Aug 13 17:34:09 steelpick systemd-logind[16201]: Got message type=method_call 
> sender=:1.39 destination=:1.224 object=/org/freedesktop/login1/session/_32 
> interface=org.freedesktop.login1.Session member=SetIdleHint cookie=34 
> reply_cookie=0 error=n/a
> Aug 13 17:34:09 steelpick systemd-logind[16201]: Sent message 
> type=method_call sender=n/a destination=org.freedesktop.DBus 
> object=/org/freedesktop/DBus interface=org.freedesktop.DBus 
> member=GetConnectionUnixUser cookie=3105 reply_cookie=0 error=n/a
> Aug 13 17:34:09 steelpick systemd-logind[16201]: Got message 
> type=method_return sender=org.freedesktop.DBus destination=:1.224 object=n/a 
> interface=n/a member=n/a cookie=2170 reply_cookie=3105 error=n/a
> Aug 13 17:34:09 steelpick systemd-logind[16201]: Sent message type=signal 
> sender=n/a destination=n/a object=/org/freedesktop/login1/session/_32 
> interface=org.freedesktop.DBus.Properties member=PropertiesChanged 
> cookie=3106 reply_cookie=0 error=n/a
> Aug 13 17:34:09 steelpick systemd-logind[16201]: Sent message type=signal 
> sender=n/a destination=n/a object=/org/freedesktop/login1/seat/seat0 
> interface=org.freedesktop.DBus.Properties member=PropertiesChanged 
> cookie=3107 reply_cookie=0 error=n/a
> Aug 13 17:34:09 steelpick systemd-logind[16201]: Sent message type=signal 
> sender=n/a destination=n/a object=/org/freedesktop/login1/user/_1000 
> interface=org.freedesktop.DBus.Properties member=PropertiesChanged 
> cookie=3108 reply_cookie=0 error=n/a
> Aug 13 17:34:09 steelpick systemd-logind[16201]: Sent message type=signal 
> sender=n/a destination=n/a object=/org/freedesktop/login1 
> interface=org.freedesktop.DBus.Properties member=PropertiesChanged 
> cookie=3109 reply_cookie=0 error=n/a
> Aug 13 17:34:09 steelpick systemd-logind[16201]: device-enumerator: scan all 
> dirs
> Aug 13 17:34:09 steelpick systemd-logind[16201]:   device-enumerator: 
> scanning /sys/bus
> Aug 13 17:34:09 steelpick systemd-logind[16201]:   device-enumerator: 
> scanning /sys/class
> Aug 13 17:34:09 steelpick systemd-logind[16201]: External (1) displays 
> connected.
> Aug 13 17:34:09 steelpick systemd-logind[16201]: Refusing operation, as it is 
> turned off.
> ...

I'd would be nice to see what's going on here...

> Aug 13 17:37:48 steelpick NetworkManager[1420]:   (wlan0): DHCPv4 state 
> changed bound -> bound
> Aug 13 17:37:48 steelpick NetworkManager[1420]:   (wlan0): Lowering 
> IPv6 MTU (1280) to match device MTU (0)
> Aug 13 17:37:48 steelpick NetworkManager[1420]:   (wlan0): IPv6 MTU (0) 
> smaller than 1280, adjusting
> Aug 13 17:37:48 steelpick NetworkManager[1420]:   (wlan0): Raising 
> device MTU (0) to match IPv6 MTU (1280)
> Aug 13 17:37:48 steelpick dbus[1307]: [system] Activating via systemd: 
> service name='org.freedesktop.nm_dispatcher' 
> unit='dbus-org.freedesktop.nm-dispatcher.service'
> Aug 13 17:37:48 steelpick dhclient[22949]: bound to 147.32.219.249 -- renewal 
> in 261 seconds.
> Aug 13 17:37:48 steelpick systemd[1]: Starting Network Manager Script 
> Dispatcher Service...
> Aug 13 17:37:48 steelpick systemd-logind[16201]: Got message type=signal 
> sender=:1.0 destination=n/a 
> object=/org/freedesktop/systemd1/unit/NetworkManager_2ddispatcher_2eservice 
> interface=org.freedesktop.DBus.Properties member=P
> Aug 13 17:37:48 steelpick NetworkManager[1420]:   sleep requested 
> (sleeping: no  enabled: yes)
> Aug 13 17:37:48 steelpick systemd-logind[16201]: device-enumerator: scan all 
> dirs
> Aug 13 17:37:48 steelpick NetworkManager[1420]: