Re: [systemd-devel] DynamicUser in instantiated (and socket-activated) units
On Tue, Jan 21, 2020 at 05:08:14PM +0100, Lennart Poettering wrote: > if you speciy the same user name its going to have the same uid. > > use something like this: > > ... > [Service] > ... > User=foo-%i > DynamicUser=1 > ... > > That way you have a separate user for each instance, and the user is > called "foo-" suffixed with the instance ID. And each UID is > dynamically assigned. Great, it works, thanks! I see, so without a User= line, username is the same as the unit name (before @)... apparently I didn't read systemd.exec manpage carefully enough. Sincerely, L. -- Leonid Isaev ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] DynamicUser in instantiated (and socket-activated) units
Hi, I am trying to sandbox processes that run via instantiated units and the DynamicUser feature seems like a nice solution. However, when I start several such units simultaneously, the dynamic UID, while random, is the same for all instances (see below). Is this expected behavior and is there any way to make UID different for each instance? For example: -8<- [root@hyena ~]# systemctl cat sleep@.service # /etc/systemd/system/sleep@.service [Unit] Description=A test unit After=network.target [Service] Type=simple DynamicUser=yes ExecStart=/usr/bin/sleep 180 [root@hyena ~]# systemctl start sleep@1.service [root@hyena ~]# systemctl start sleep@2.service [root@hyena ~]# ps auxwwn ... 65086 154271 0.0 0.0 5292 704 ?Ss 15:45 0:00 /usr/bin/sleep 180 65086 154274 0.0 0.0 5292 704 ?Ss 15:45 0:00 /usr/bin/sleep 180 ^ [root@hyena ~]# journalctl | tail ... Jan 21 15:45:53 hyena systemd[1]: Started A test unit. Jan 21 15:45:55 hyena systemd[1]: Started A test unit. ->8- Same applies to socket-activated services whose .socket unit has Accept=true. For example: -8<- [root@hyena ~]# systemctl cat convert.socket # /etc/systemd/system/convert.socket [Unit] Description=Convert Socket Conflicts=convert.service [Socket] ListenStream=15000 Accept=true [Install] WantedBy=sockets.target [root@hyena ~]# systemctl cat convert@.service # /etc/systemd/system/convert@.service [Unit] Description=A conversion program After=network.target [Service] Type=simple DynamicUser=yes StandardInput=socket ExecStart=/etc/systemd/scripts/convert.sh ->8- Thanks in advance, L. -- Leonid Isaev ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] DynamicUser in instantiated (and socket-activated) units
On Tue, Jan 21, 2020 at 03:53:10PM +, Leonid Isaev wrote: > I am trying to sandbox processes that run via instantiated units and > the DynamicUser feature seems like a nice solution. However, when I start > several such units simultaneously, the dynamic UID, while random, is the same > for all instances (see below). Is this expected behavior and is there any way > to make UID different for each instance? Sorry, forgot to mention, it is systemd 244 on Arch Linux. Thanks, L. -- Leonid Isaev ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-networkd -- Cannot acquire DHCP lease on bridge interface
Hi, On Wed, Sep 24, 2014 at 08:14:55PM -0700, James Lott wrote: Hello, There is no .network file for the bridge. Systemd-networkd is currently only in charge of setting up the interface. As you can see from the provided output in my original email, I am running the dhcpcd service directly from the command line (the output from each run of the dhcpcd service is included in that email as well). I asked because you could try and see if networkd can acquire a lease by itself, without dhcpcd (I don't expect it to). Also, could you run dhcpcd with -d -t 0 (debug output, no timeout) to see what it's doing? I have seen a similar issue with networkd and bonding of interfaces. It turned out that the way networkd works with links is racy, so in ~70% of boots dhcp lease attempts failed both via networkd and dhcpcd. The only solution which I found was to use netctl (should be availabel on ALARM) where you can explicitly specify a precise order in which links should be managed. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpLL9IO0V0UE.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-networkd -- Cannot acquire DHCP lease on bridge interface
Hi, On Thu, Sep 25, 2014 at 04:56:55PM -0700, James Lott wrote: Actually, the reason I am using dhcpcd fro mthe command line is as a debugging measure, because I originally setup a .network file for this interface to attempt to allow systemd-networkd to handle acquiring the DHCP lease. You could run networkd manually as # SYSTEMD_LOG_LEVEL=debug /usr/lib/systemd/systemd-networkd but this will also show endless DISCOVER attempts. In my case, I controlled the DHCP server, and according to its logs the lease is actually assigned but the client never receives it. So, I suspect a bug either in kernel or systemd because packets get lost in the bridge (or bond in my case). I suspect the former because restarting networkd didn't help (i.e. the DHCP lease never got received). Yuck. I'm really not a fan of netctl, and would probably sooner hack together some oneshot service files that manually setup the interfaces and acquire leases. So it sounds like systemd-networkd is not quite ready for prime time when it comes to being a complete interface management solution. I guess that's what I get for living life on the edge ;) Netctl is better in this situation because it allows ordering of different profiles w.r.t. each other because they are just systemd services (in networkd language this would be ordering of different .net* units if such existed). So you can first set up vlans, then bridge and do the DHCP stuff. There is an additional problem with networkd: you never know how to order against it. Sure there are network* targets (and ideally things _should_ work) but they are useless in this context because they can be reached before (virtual) devices are actually initialized. OTOH, when a netctl script successfully returns, you know that things are properly set up. Hopefully this thread attracts relevant attention because I don't know how to debug this... HTH, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgp88gtVXlpiz.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-networkd -- Cannot acquire DHCP lease on bridge interface
Hi, On Wed, Sep 24, 2014 at 07:16:03PM -0700, James Lott wrote: However, when I try to acquire a dhcp lease through the bridge interface, I am unable to do so. Removing the bridge interface and re-adding it using brctl (as well as its vlan member) then allows me to gain a lease. Details are included below. This is on arch linux ARM, systemd 216-r3. As always, I'm happy to provide any additional information required! What does the .network file for the bridge do, i.e. what are its IP settings? Also, how do you start dhcpcd? Via the stock ArchLinux dhcpcd@.service? Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpLbgK59Yo9L.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Misleading udev error messages regarding virtual interfaces
Hi, On Fri, Aug 15, 2014 at 06:20:07PM +0200, Lennart Poettering wrote: On Sun, 06.07.14 12:43, Leonid Isaev (lis...@umail.iu.edu) wrote: Hi, Sorry for a delayed reply. On Thu, Jul 03, 2014 at 01:46:53PM +0200, Lennart Poettering wrote: it would be good to know what the precise error output is you get now with this new change... With systemd-215 udevd still complains (and segfaults) about the virtual interface: -- $ journalctl | grep udevd Jul 06 12:21:05 hermes systemd-udevd[46]: starting version 215 Jul 06 12:21:05 hermes systemd-udevd[226]: starting version 215 Jul 06 12:21:06 hermes systemd-udevd[234]: renamed network interface wlan0 to wlp1s0 Jul 06 12:21:09 hermes systemd-udevd[226]: worker [233] terminated by signal 11 (Segmentation fault) Jul 06 12:21:09 hermes kernel: systemd-udevd[233]: segfault at 0 ip 7ff524a0571a sp 7fffc8a69540 error 4 in libc-2.19.so[7ff524907000+1a4000] Jul 06 12:21:09 hermes systemd-udevd[226]: worker [233] failed while handling '/devices/virtual/net/veth7DH07K' -- As before, things seem to work i.e. I can still see servers inside containers. The kernel is 3.15.3. Does this still occur with current systemd git? I haven't tested the git master yet, but with systemd 215 and kernels 3.15.5, I did not see a single segfault... Any chance to get a backtrace for this with current git? I'll try tomorrow. Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpxD_HBfNaSB.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Missing forked processes in 'systemctl status'
Hi, On Wed, Aug 13, 2014 at 03:29:40PM +0200, Lennart Poettering wrote: On Mon, 11.08.14 13:22, Leonid Isaev (lis...@umail.iu.edu) wrote: Hi, I am seeing an oddity in the CGroup output of systemctl status ran on some units. On the other hand, systemd-cgls shows correct information. Here is an example: -- $ systemctl status netctl@wan.service netctl@wan.service - DHCP connection on bond0 Loaded: loaded (/etc/systemd/system/netctl@wan.service; enabled) Active: active (exited) since Mon 2014-08-11 11:51:05 EDT; 1h 20min ago Docs: man:netctl.profile(5) Process: 645 ExecStart=/usr/lib/network/network start %I (code=exited, status=0/SUCCESS) Main PID: 645 (code=exited, status=0/SUCCESS) $ systemctl status netctl@wlan.service netctl@wlan.service - Secure wireless uplink Loaded: loaded (/etc/systemd/system/netctl@wlan.service; enabled) Active: active (exited) since Mon 2014-08-11 11:50:58 EDT; 1h 16min ago Docs: man:netctl.profile(5) Process: 489 ExecStart=/usr/lib/network/network start %I (code=exited, status=0/SUCCESS) Main PID: 489 (code=exited, status=0/SUCCESS) CGroup: /system.slice/system-netctl.slice/netctl@wlan.service 501 wpa_supplicant -B -P /run/wpa_supplicant_wlp3s0.pid -i wlp3s.. When you use systemctl -p ControlGroup show on the two services, do they both show valid cgroup paths? No. -- $ systemctl show netctl@wlan.service | grep -i controlgroup ControlGroup=/system.slice/system-netctl.slice/netctl@wlan.service $ systemctl show netctl@wan.service | grep -i controlgroup nothing -- What's the Type= of the units? netclt@.service is Type=oneshot: -- $ cat /usr/lib/systemd/system/netctl@.service [Unit] Description=Networking for netctl profile %I Documentation=man:netctl.profile(5) Before=network.target netctl.service Wants=network.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/lib/network/network start %I ExecStop=/usr/lib/network/network stop %I KillMode=none -- Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpvtoZE_fN18.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Missing forked processes in 'systemctl status'
Hi, On Wed, Aug 13, 2014 at 06:40:48PM +0200, Lennart Poettering wrote: On Wed, 13.08.14 12:30, Leonid Isaev (lis...@umail.iu.edu) wrote: What's the Type= of the units? netclt@.service is Type=oneshot: -- $ cat /usr/lib/systemd/system/netctl@.service [Unit] Description=Networking for netctl profile %I Documentation=man:netctl.profile(5) Before=network.target netctl.service Wants=network.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/lib/network/network start %I ExecStop=/usr/lib/network/network stop %I KillMode=none If processes stay around Type=oneshot is wrong really. Type=forking is more appropriate then. Hmm. That's a good point... I'll ask about this, but my (limited) understanding of the reasoning for this choice is that network script does not always fork a process. For example, setting up a macvlan does not require a daemon to hang around. This still doesn't explain why systemctl misses the cgroup information... Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpWe61EKyJbW.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Missing forked processes in 'systemctl status'
Hi, On Wed, Aug 13, 2014 at 07:45:28PM +0200, Lennart Poettering wrote: Well, maybe some script in the boot process invokes systemctl daemon-reload or so? Anything in the logs? None that I can find... Also, journalctl | grep -i reload returns nothing. But anyway, I can reproduce this by disabling all networking-related services, rebooting (to a networkless system), and then enabling/starting the relevant (above) services. I'll try in a clean VM next and get back here... As I said before, systemd-cgls shows the correct cgroup tree for all units. Does it simply look in /proc, unlike systemctl? Maybe netctl is used in your initrd, and the reexec for the transition from initrd to the host os is the issue here? No, netctl is not a part of my initramfs image... and neither is systemd for that matter. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpFNiuyP8cay.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Missing forked processes in 'systemctl status'
Hi, I am seeing an oddity in the CGroup output of systemctl status ran on some units. On the other hand, systemd-cgls shows correct information. Here is an example: -- $ systemctl status netctl@wan.service netctl@wan.service - DHCP connection on bond0 Loaded: loaded (/etc/systemd/system/netctl@wan.service; enabled) Active: active (exited) since Mon 2014-08-11 11:51:05 EDT; 1h 20min ago Docs: man:netctl.profile(5) Process: 645 ExecStart=/usr/lib/network/network start %I (code=exited, status=0/SUCCESS) Main PID: 645 (code=exited, status=0/SUCCESS) $ systemctl status netctl@wlan.service netctl@wlan.service - Secure wireless uplink Loaded: loaded (/etc/systemd/system/netctl@wlan.service; enabled) Active: active (exited) since Mon 2014-08-11 11:50:58 EDT; 1h 16min ago Docs: man:netctl.profile(5) Process: 489 ExecStart=/usr/lib/network/network start %I (code=exited, status=0/SUCCESS) Main PID: 489 (code=exited, status=0/SUCCESS) CGroup: /system.slice/system-netctl.slice/netctl@wlan.service 501 wpa_supplicant -B -P /run/wpa_supplicant_wlp3s0.pid -i wlp3s.. -- However, -- $ systemd-cgls /system.slice/system-netctl.slice/netctl@wlan.service /system.slice/system-netctl.slice/netctl@wlan.service: 501 wpa_supplicant -B -P /run/wpa_supplicant_wlp3s0.pid -i wlp3s0 -D ... $ systemd-cgls /system.slice/system-netctl.slice/netctl@wan.service /system.slice/system-netctl.slice/netctl@wan.service: 663 dhcpcd -4 -q -t 30 -L bond0 -- So, both units are actually instances of the same netctl@.service. This service calls a script (/usr/lib/network/network) which in turn starts wpa_supplicant or dhcpcd. The difference between the two cases is that dhcpcd forks yet another process: -- $ journalctl -u netctl@wan.service | grep forked Aug 11 11:51:05 borei dhcpcd[650]: forked to background, child pid 663 -- This is systemd-215 running on ArchLinux. Any ideas why this is happening? Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpqSj7Z21wTU.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-resolved cannot survive router reinstall
Hi, On Sat, Aug 09, 2014 at 10:59:30AM -0700, Anatol Pomozov wrote: Hi I have a router where I experiment with OpenWRT. I sysupdate (i.e. reinstall) openwrt regularly, once or twice a week. I also have an Arch home server with the latest systemd. The machine connected via ethernet cable. Every time I reboot router it looses information about current DHCP leases and devices need to renew it. All devices (ipads/androids/music center/..) are able to renew leases, openwrt ui shows valid new dhcp leases. And only the Arch machine does not. It looks like other dhcp clients have some kind of heartbeat message and renew leases when the network is back. But not systemd-resolved. To restore the system back I need to suspend/wakeup the machine and it is annoying. Is it a known issue? Is there any additional information I can provide? Are you possibly confusing resolved with networkd? The former is for setting up DNS and is not really needed on a small LAN. AFAIK, networkd will not renew a lease if DHCP server goes down and then up. OTOH, why is this a problem: do you have an IP collision after the router is back up (because another device got your IP)? Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgppzzTaxoBj3.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] right way to log to rsyslog/syslog only?
Hi, On Thu, Aug 07, 2014 at 02:06:07PM +0200, Frantisek Hanzlik wrote: '/etc/systemd/system.conf': [Manager] LogTarget=syslog-or-kmsg DefaultStandardOutput=syslog Leave 'LogTarget=' to its default value (journal-or-kmsg). It's good that I have no /var/log/journal/* files, but - journald is still runnig (this isn't too imporatant, but when it is possible work without it, it will be better) - fundamental problem seems be, that some daemons logs not appear in rsyslog files, for unknown reason. Could you be more specific about which daemons are affected? Many daemons that are started by systemd service run in foreground (don't ask me about the logic behind this). This means that all output is sent to stdout, not syslog. Journald collects this output and forwards it to syslog -- hence my recommendation above. For example, sshd(8) now runs with '-D'. Of course, some daemons might send their messages syslog even if run in foreground, but not all. A hard way to fix this is to modify service files for daemons you use to run in background and set 'Type=forking'. HTH, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpW64ANKNKmh.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] right way to log to rsyslog/syslog only?
On Thu, Aug 07, 2014 at 02:34:20PM +0200, Jon Stanley wrote: I'm not 100% sure what happens if there is a backing store, i.e. does it still store in memory? No. Perhaps understanding why you're allergic to the journal would help in figuring out solutions to the actual underlying problem. There is nothing wrong with the journald per se, but it's not a replacement for the classic syslog: journald offers only log storage, while syslog is a log processing tool. This distinction is dim on a desktop, but is very apparent even on a simple server machine. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpj26XVDgpUh.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] right way to log to rsyslog/syslog only?
Hi, On Thu, Aug 07, 2014 at 06:11:39PM +, Jóhann B. Guðmundsson wrote: On 08/07/2014 04:12 PM, Leonid Isaev wrote: Perhaps understanding why you're allergic to the journal would help in figuring out solutions to the actual underlying problem. There is nothing wrong with the journald per se, but it's not a replacement for the classic syslog Yes it is. Hmm, reading my message above, I can see that it wasn't clear enough -- sorry. Perhaps an example can clarify things. Take dnsmasq which under normal operation logs _lots_ of DHCP-related messages, even on a tiny network of ~20 (crappy Android) devices. These messages fall into 2 categories: routine (log_level info -- DHCPREQUEST, DHCPACK, etc.) and security-related (log_level warn -- DNS rebind attacks e.g.). I want the former to be volatile (stored in /run/log), while the latter on-disk (in /var/log). While there are many ways to accomplish this with rsyslog/syslog-ng filters, I'd very much like to know how to do this with journald. Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpYQhD4Lmcgr.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] right way to log to rsyslog/syslog only?
On Thu, Aug 07, 2014 at 08:01:31PM +, Jóhann B. Guðmundsson wrote:
Give me an actual working example how this is solved using rsyslog/syslog-ng
filters
A quick (and probably dirty) way with syslog-ng:
--
% grep dnsmasq /etc/syslog-ng/syslog-ng.conf
destination d_dnsmasq { file(/run/log/dnsmasq.log); };
filter f_daemon { facility(daemon) and not level(debug) and not program(hostap)
and not program(dnsmasq-dhcp); };
filter f_dnsmasq { program(dnsmasq-dhcp); };
log { source(src); filter(f_dnsmasq); destination(d_dnsmasq); };
--
So, dnsmasq-dhcp is the prefix (used by dnsmasq by default) for normal
messages, while dnsmasq -- for everything else. Here is some statistics:
--
% uptime
16:38:29 up 22 days, 22:05, 1 user, load average: 0.00, 0.01, 0.05
% wc -l /run/log/dnsmasq.log*
1212 /run/log/dnsmasq.log
972 /run/log/dnsmasq.log.1
2077 /run/log/dnsmasq.log.2
958 /run/log/dnsmasq.log.3
5219 total
% head -n 2 /run/log/dnsmasq.log
2014-08-03T00:05:42.00-04:00 metal-0 dnsmasq-dhcp[460]: DHCPREQUEST(br0)
10.0.0.4 30:39:26:e3:ec:4e
2014-08-03T00:05:42.00-04:00 metal-0 dnsmasq-dhcp[460]: DHCPACK(br0)
10.0.0.4 30:39:26:e3:ec:4e android-2f74c9ab3fa43caa
% for i in /var/log/daemon.log*; do echo $i; grep dnsmasq $i | wc -l; done
/var/log/daemon.log
0
/var/log/daemon.log.1
1
/var/log/daemon.log.2
2
/var/log/daemon.log.3
11
/var/log/daemon.log.4
11
/var/log/daemon.log.5
0
/var/log/daemon.log.6
0
/var/log/daemon.log.7
23
/var/log/daemon.log.8
30
% grep dnsmasq /var/log/daemon.log.1
2014-08-02T15:46:05.00-04:00 metal-0 dnsmasq[460]: possible DNS-rebind
attack detected: direct.stroyka.ru
--
Sorry for a long reply...
--
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4
C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
pgpAhca1Wxzhm.pgp
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] right way to log to rsyslog/syslog only?
Hi, On Thu, Aug 07, 2014 at 09:44:47PM +, Jóhann B. Guðmundsson wrote: So basically you want to log everything to /run ( volatile ) and filter out everything above a certain log-level and store that persistent in it's own journal ( basically store the output from this journalctl -p err persistently ) Or you want to log everything to /run ( volatile ) and filter out everything above a certain log-level for a specific user,unit,command whatever and store that persistent in it's own journal. ( using your example store the output from this journalctl -p err _SYSTEMD_UNIT=dnsmasq.service persistently ) My original motivation was to reduce HDD spin-ups (academic, I know). So I had to identify sources of frequent logging activity and figure out which log messages are actually valuable and which can be discarded on reboot. The same rationality applies to remote logging, e.g. only auth-level events and critical hardware telemetry should be sent to a log-server. One of the Samsung guys proposed something similar to the former a while back ( and I think he signed himself up to it ) but as far as I can tell his work has not landed yet. ( afaikt requires changes to journald-server.c|||introduce something like SplitMode=priority-err |etc ). Thanks for letting me know aboout this work, but from the above description it seems rather limited. I brought up the log-levels only as an example. In practice one needs to be able to filter using _any_ message attribute. For instance, message body (iptables traffic, output of frequently-run systemd timers -- drop the useless Start/Stop-type messages, HostAp logs) and facility (kernel/daemon/...). I would not expect anything like this soon since Andy NAK their SCM_PROCINFO stuff and they are probably to busy re-writing/re-implementing it as SCM_IDENTY together with him but one of the Samsung guys can comment if they had started working on or had otherwise looked into this but as things stand now this cannot be done afaikt. IMHO, the central technical problem (I am not going to argue about design principles) of journald is that it is an all or nothing solution. Unfortunately, this inflexibility makes it only useful as a supplimentary logger... Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpGkfWoCl5FC.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [networkd] intermittent failure to get DHCP lease on a bond interface
Hi, Ever since updating to kernel 3.16, systemd-networkd very often fails to get a DHCPv4 lease on a bond interface. This happens irregularly which makes me suspect some kind of a race. The bond enslaves eth and wlan cards. Here is the config: -- /etc/systemd/network/bond0.netdev [NetDev] Name=bond0 Kind=bond /etc/systemd/network/bond0.network [Match] Name=bond0 [Network] Description=Bond interface DHCP=v4 [DHCPv4] UseDNS=false /etc/systemd/network/eth.network [Match] Name=eno1 [Network] Description=Wired interface Bond=bond0 /etc/systemd/network/wlan.network [Match] Name=wlp3s0 [Network] Description=Wireless interface Bond=bond0 $ cat /etc/modprobe.d/bonding.conf options bonding mode=active-backup options bonding primary=eno1 options bonding miimon=1000 -- The wlan interface is managed by wpa_supplicant which is ordered After=systemd-networkd.service. There is nothing suspicious in journald and by running networkd via cmdline with SYSTEMD_LOG_LEVEL=debug (I only see endless DISCOVER messages): -- $ journalctl -u systemd-networkd.service -- Logs begin at Tue 2014-08-05 10:13:29 EDT, end at Tue 2014-08-05 11:05:07 EDT. -- Aug 05 10:13:29 borei systemd[1]: Starting Network Service... Aug 05 10:13:29 borei systemd-networkd[446]: bond0 : netdev ready Aug 05 10:13:29 borei systemd-networkd[446]: lo : gained carrier Aug 05 10:13:29 borei systemd-networkd[446]: bond0 : link configured Aug 05 10:13:29 borei systemd[1]: Started Network Service. Aug 05 10:13:29 borei systemd-networkd[446]: eno1: link configured Aug 05 10:13:29 borei systemd-networkd[446]: wlp3s0 : link configured Aug 05 10:13:33 borei systemd-networkd[446]: wlp3s0 : gained carrier Aug 05 10:13:34 borei systemd-networkd[446]: bond0 : gained carrier -- Interestingly, on the server side (dnsmasq) I see DISCOVER and OFFER messages for an IP address every 3 sec, but on the client no address is assigned to bond0. The bond itself is set up properly. And, of course, dhcpcd _is_ able to obtain a lease (I can also get a working network by assigning a static IP on the correct subnet): -- $ journalctl -u dhcpcd@bond0.service -- Logs begin at Tue 2014-08-05 10:13:29 EDT, end at Tue 2014-08-05 11:13:29 EDT. -- Aug 05 10:24:13 borei systemd[1]: Starting dhcpcd on bond0... Aug 05 10:24:13 borei dhcpcd[916]: version 6.4.3 starting Aug 05 10:24:13 borei dhcpcd[916]: all: IPv6 kernel autoconf disabled Aug 05 10:24:13 borei dhcpcd[916]: bond0: adding address fe80::18f7:74d:5764:92e9 Aug 05 10:24:13 borei dhcpcd[916]: if_addaddress6: Operation not supported Aug 05 10:24:13 borei dhcpcd[916]: error writing DUID: /etc/dhcpcd.duid: Read-only file system Aug 05 10:24:13 borei dhcpcd[916]: DUID 00:03:00:01:f0:1f:af:4d:36:99 Aug 05 10:24:13 borei dhcpcd[916]: bond0: IAID af:4d:36:99 Aug 05 10:24:14 borei dhcpcd[916]: bond0: rebinding lease of 10.0.0.21 Aug 05 10:24:19 borei dhcpcd[916]: bond0: leased 10.0.0.21 for 86400 seconds Aug 05 10:24:19 borei dhcpcd[916]: bond0: adding route to 10.0.0.0/24 Aug 05 10:24:19 borei dhcpcd[916]: bond0: adding default route via 10.0.0.1 Aug 05 10:24:19 borei dhcpcd[916]: forked to background, child pid 923 Aug 05 10:24:19 borei systemd[1]: Started dhcpcd on bond0. $ systemctl cat dhcpcd@bond0.service # /usr/lib/systemd/system/dhcpcd@.service [Unit] Description=dhcpcd on %I Wants=network.target Before=network.target BindsTo=sys-subsystem-net-devices-%i.device After=sys-subsystem-net-devices-%i.device [Service] Type=forking PIDFile=/run/dhcpcd-%I.pid ExecStart=/usr/bin/dhcpcd -q -w %I ExecStop=/usr/bin/dhcpcd -x %I [Install] WantedBy=multi-user.target -- I am a bit at a loss of how to debug this further... Any ideas? Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpkbppXRDVib.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-sysusers and gshadow
Hi, Thanks for the explanation... On Mon, Jul 07, 2014 at 12:26:03PM +0200, Lennart Poettering wrote: I wasn#t aware of grpck, and quite frankly don't think it makes much sense, what the tool is doing. Why? Checking syntax can never hurt... Does it mean that on each update, a package manager should touch /etc/.updated? Hmm? No. A package manager should touch /usr after having done its work. Just to see if I understand: this would mean that ConditionNeedsUpdate = .true. for /etc, no? So, we _do_ want systemd-sysusers.service, ldconfig.service, et al. to run on next boot after an update? Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpbpZbXN3pTQ.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Misleading udev error messages regarding virtual interfaces
Hi, On Mon, Jul 07, 2014 at 03:02:47PM +0200, Tom Gundersen wrote: On Sun, Jul 6, 2014 at 6:43 PM, Leonid Isaev lis...@umail.iu.edu wrote: Hi, Sorry for a delayed reply. On Thu, Jul 03, 2014 at 01:46:53PM +0200, Lennart Poettering wrote: it would be good to know what the precise error output is you get now with this new change... With systemd-215 udevd still complains (and segfaults) about the virtual interface: -- $ journalctl | grep udevd Jul 06 12:21:05 hermes systemd-udevd[46]: starting version 215 Jul 06 12:21:05 hermes systemd-udevd[226]: starting version 215 Jul 06 12:21:06 hermes systemd-udevd[234]: renamed network interface wlan0 to wlp1s0 Jul 06 12:21:09 hermes systemd-udevd[226]: worker [233] terminated by signal 11 (Segmentation fault) Jul 06 12:21:09 hermes kernel: systemd-udevd[233]: segfault at 0 ip 7ff524a0571a sp 7fffc8a69540 error 4 in libc-2.19.so[7ff524907000+1a4000] Jul 06 12:21:09 hermes systemd-udevd[226]: worker [233] failed while handling '/devices/virtual/net/veth7DH07K' -- The original problem (with the error message) should be fixed now in git, please let me know if that is not the case. Great, thanks -- I'll test it as soon as I get back to my build machine. This seems to be a different issue though. One that I am not able to reproduce. Could you get the backtrace for this? You mean the segmentation fault? This is very irregular (it occurs approx. every 3nd boot), so I'll have to chase it... Best, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgp5fMmchr3h5.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-sysusers and gshadow
On Mon, Jul 07, 2014 at 05:40:42PM +0200, Lennart Poettering wrote:
On Mon, 07.07.14 11:08, Leonid Isaev (lis...@umail.iu.edu) wrote:
Hi,
Thanks for the explanation...
On Mon, Jul 07, 2014 at 12:26:03PM +0200, Lennart Poettering wrote:
I wasn#t aware of grpck, and quite frankly don't think it makes much
sense, what the tool is doing.
Why? Checking syntax can never hurt...
Well, I am not opposed to that. I am just saying that otherwise the
current logic so nicely considers an account with a missing counterpart
in /etc/shadow disabled with no way to log in, which is exactly what we
want here. However, grpck tool breaks that...
Ah, right. So you mean grpck _and_ pwck.
Is this a new systemd-only thinking, or is it something to be taken to the
shadow upstream (because {grp,pw}ck is provided by shadow)?
Does it mean that on each update, a package manager should touch
/etc/.updated?
Hmm? No. A package manager should touch /usr after having done its work.
Just to see if I understand: this would mean that ConditionNeedsUpdate =
.true.
for /etc, no? So, we _do_ want systemd-sysusers.service, ldconfig.service,
et
al. to run on next boot after an update?
Well, the idea is that they are NOPs if they already ran from postinst...
OK. Fixing post_install scripts of every package is probably not going to
happen, so running the above services on-boot seems indeed better.
Cheers,
--
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4
C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
pgpyM02us48oK.pgp
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Misleading udev error messages regarding virtual interfaces
Hi, Sorry for a delayed reply. On Thu, Jul 03, 2014 at 01:46:53PM +0200, Lennart Poettering wrote: it would be good to know what the precise error output is you get now with this new change... With systemd-215 udevd still complains (and segfaults) about the virtual interface: -- $ journalctl | grep udevd Jul 06 12:21:05 hermes systemd-udevd[46]: starting version 215 Jul 06 12:21:05 hermes systemd-udevd[226]: starting version 215 Jul 06 12:21:06 hermes systemd-udevd[234]: renamed network interface wlan0 to wlp1s0 Jul 06 12:21:09 hermes systemd-udevd[226]: worker [233] terminated by signal 11 (Segmentation fault) Jul 06 12:21:09 hermes kernel: systemd-udevd[233]: segfault at 0 ip 7ff524a0571a sp 7fffc8a69540 error 4 in libc-2.19.so[7ff524907000+1a4000] Jul 06 12:21:09 hermes systemd-udevd[226]: worker [233] failed while handling '/devices/virtual/net/veth7DH07K' -- As before, things seem to work i.e. I can still see servers inside containers. The kernel is 3.15.3. Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpV0OOFAJwHM.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Is there a reason to forcefully create /etc/mtab?
Hi, I have a read-only / filesystem and /etc/mtab points to /proc/self/mounts as it should. So, in systemd-215 tmpfile.d fails to create a symbolic link /etc/mtab because /usr/lib/tmpfiles.d/etc.conf contains is a line L+ /etc/mtab - - - - ../proc/self/mounts. Is this intentional? Besides failing on ro /, it is also confusing because /etc/mtab can be supplied by a package (in archlinux, the 'filesystem' package), so why tmpfiles instead of including this symlink with systemd? The same question applies to the entire etc.conf: why does tmpfiles touch /etc at all, especially if /etc is already properly set up? Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpLVP4W5dKM6.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd fails to get DHCPv4 lease with disabled IPv6
Hi, With systemd-215 networkd fails to set up the DHCPv4 on WAN interface: -- $ journalctl -u systemd-networkd.service | grep wlp1s0 Jul 06 12:21:07 hermes systemd-networkd[355]: wlp1s0 : link configured Jul 06 12:21:08 hermes systemd-networkd[355]: wlp1s0 : gained carrier Jul 06 12:21:08 hermes systemd-networkd[355]: wlp1s0 : could not start IPv6 router discovery Jul 06 12:21:08 hermes systemd-networkd[355]: wlp1s0 : failed -- Interestingly, if I restart networkd, the (DHCPv4) lease _is_ obtained, but the default route is _not_ set. The reason why IPv6 router discovery fails is because I boot with 'ipv6.disable=1' on the kernel cmdline. So, is there now a hard dependency on IPv6 being enabled? Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgp83Y_9BlFWH.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a reason to forcefully create /etc/mtab?
On Sun, Jul 06, 2014 at 09:15:28PM +0400, Ivan Shapovalov wrote: On Sunday 06 July 2014 at 13:13:55, Mike Gilbert wrote: On Sun, Jul 6, 2014 at 1:08 PM, Ivan Shapovalov intelfx...@gmail.com wrote: On Sunday 06 July 2014 at 13:01:22, Leonid Isaev wrote: Hi, I have a read-only / filesystem and /etc/mtab points to /proc/self/mounts as it should. So, in systemd-215 tmpfile.d fails to create a symbolic link /etc/mtab because /usr/lib/tmpfiles.d/etc.conf contains is a line L+ /etc/mtab - - - - ../proc/self/mounts. Is this intentional? Besides failing on ro /, it is also confusing because /etc/mtab can be supplied by a package (in archlinux, the 'filesystem' package), so why tmpfiles instead of including this symlink with systemd? The same question applies to the entire etc.conf: why does tmpfiles touch /etc at all, especially if /etc is already properly set up? Thanks, L+ (as well as any other + directives) only force-overwrite files if this is needed, e. g. if a symlink points to the wrong desination. Right. I think the path matching is a little naive; Using a simple string comparison, /proc/self/mounts != ../proc/self/mounts even though both paths refer to the same object. No, they aren't referring to the same object. This makes a difference when you mount a foreign system image for maintainance. Cool :( So... the solution would be for distro packages to ship mtab as a symlink to ../proc instead of /proc? Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpzLf2uY3vGl.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a reason to forcefully create /etc/mtab?
Hi, On Sun, Jul 06, 2014 at 08:13:56PM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Sun, Jul 06, 2014 at 01:44:05PM -0400, Leonid Isaev wrote: So... the solution would be for distro packages to ship mtab as a symlink to ../proc instead of /proc? No, the latter is fine, or even better. The solution is for systmed-tmpfiles to stop complaining when the fs is readonly. Well, I actually would like it to complain (that's why I keep / read-only). I'd rather change L+ to L... Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpMEK60D0vTU.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd fails to get DHCPv4 lease with disabled IPv6
On Sun, Jul 06, 2014 at 08:43:01PM +0200, Tom Gundersen wrote: On Sun, Jul 6, 2014 at 7:17 PM, Leonid Isaev lis...@umail.iu.edu wrote: Hi, With systemd-215 networkd fails to set up the DHCPv4 on WAN interface: -- $ journalctl -u systemd-networkd.service | grep wlp1s0 Jul 06 12:21:07 hermes systemd-networkd[355]: wlp1s0 : link configured Jul 06 12:21:08 hermes systemd-networkd[355]: wlp1s0 : gained carrier Jul 06 12:21:08 hermes systemd-networkd[355]: wlp1s0 : could not start IPv6 router discovery Jul 06 12:21:08 hermes systemd-networkd[355]: wlp1s0 : failed -- Interestingly, if I restart networkd, the (DHCPv4) lease _is_ obtained, but the default route is _not_ set. The reason why IPv6 router discovery fails is because I boot with 'ipv6.disable=1' on the kernel cmdline. So, is there now a hard dependency on IPv6 being enabled? Hm, this is unfortunate. In the meantime you can only enable DHCPv4 by setting DHCP=v4 (as opposed to DHCP=yes). That worked... thanks. BTW, is yes/true still a valid argument for DHCP (because the manpage says otherwise)? Best, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpnK_trkgcLi.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-sysusers and gshadow
Hi, Shouldn't systemd-sysusers update /etc/gshadow when adding 'basic' groups? From sysusers.c I don't see that gshadow (and shadow) is updated, and this seems to cause problems on package updates. Consider the following scenario: 1. A package is updated, so timestamp of /usr gets ahead of /etc/.updated. 2. On next boot, new groups are added to /etc/group. In the case of archlinux these are dialout, tape and cdrom -- which I had to manually groupdel. 3. gshadow is out-of-sync with group, so routine cron-based grpck fails. Does it mean that on each update, a package manager should touch /etc/.updated? Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpTYZ8wwQ0je.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Misleading udev error messages regarding virtual interfaces
On Wed, Jul 02, 2014 at 03:15:58PM +0200, Lennart Poettering wrote: On Sun, 29.06.14 17:50, Leonid Isaev (lis...@umail.iu.edu) wrote: Hi, I am seeing the following messages in my syslog on each boot: -- $ grep link config /var/log/errors.log 2014-06-29T09:31:39.000-04:00 hermes systemd-udevd[246]: Could not apply link config to br0 2014-06-29T09:31:40.000-04:00 hermes systemd-udevd[246]: Could not apply link config to veth0VRCA6 -- The bridge 'br0' is used for LXC containers and set up via networkd: -- $ cat /etc/systemd/network/lxc_bridge.netdev [NetDev] Name=br0 Kind=bridge $ cat /etc/systemd/network/lxc_bridge.network [Match] Name=br0 [Network] Description=LAN bridge for LXC containers DHCP=false [Address] Address=10.137.0.1/24 -- The interface 'vethXX' is a container part (I guess) of the veth pair. What is the meaning of the above errors, why are they printed, and is there a way to get rid of them? I have improved the error message in git to print the actual error that is happening. This should make it easier to figure out what is going wrong. Thanks! Most likely you have some .link file lying around that matches the bridge or veth device you are creating, which causes this error. No, the only .link file in my system is the vanilla /usr/lib/systemd/network/99-default.link. Does it match all possible interfaces now? The bridge is set up only via the above .netdev/.network files. The vethXX interface (with random XX) is created dynamically by the lxc tools... Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpK1IMw3rT6e.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-fsck-root semantics
On Wed, Jul 02, 2014 at 12:33:01PM -0600, Chris Murphy wrote: On Jul 2, 2014, at 5:39 AM, Daniel Drake dr...@endlessm.com wrote: Hi, I'm trying to understand dracut/systemd fsck behaviour, in the context of an ext4 filesystem root mounted read-only from dracut, remaining read-only even when the system is fully booted (kiosk-style). I see that systemd's fstab-generator rightly creates a mount unit for /sysroot from the initramfs, and causes e2fsck to be run on it from inside the dracut initramfs, before it is mounted. So far so good. It's not wrong, but it seems unnecessary to fsck an ro file system. How is it becoming inconsistent if it's read only? You still need to remount / rw for administration tasks or updates. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpyyl9U8mlO8.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Misleading udev error messages regarding virtual interfaces
Hi, I am seeing the following messages in my syslog on each boot: -- $ grep link config /var/log/errors.log 2014-06-29T09:31:39.000-04:00 hermes systemd-udevd[246]: Could not apply link config to br0 2014-06-29T09:31:40.000-04:00 hermes systemd-udevd[246]: Could not apply link config to veth0VRCA6 -- The bridge 'br0' is used for LXC containers and set up via networkd: -- $ cat /etc/systemd/network/lxc_bridge.netdev [NetDev] Name=br0 Kind=bridge $ cat /etc/systemd/network/lxc_bridge.network [Match] Name=br0 [Network] Description=LAN bridge for LXC containers DHCP=false [Address] Address=10.137.0.1/24 -- The interface 'vethXX' is a container part (I guess) of the veth pair. What is the meaning of the above errors, why are they printed, and is there a way to get rid of them? Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpoiphk4HGEq.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On Mon, Jun 09, 2014 at 10:48:31AM +0300, Leho Kraav wrote: Date: Mon, 09 Jun 2014 10:48:31 +0300 From: Leho Kraav l...@kraav.com To: Reindl Harald h.rei...@thelounge.net, systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] How to quiet cron sessions logging with systemd-212? User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 On 09.06.2014 10:43, Reindl Harald wrote: nobody cares because the developers point of view is that what is interesting for them needs to be also faced by the sysadmin otherwise this would be only logged in debug-mode and bugreports not closed: https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c3 frankly if that messages would at least have a prefix or a different process than systemd one could filter them out with rsyslog.conf without supress relevant boot messages Thanks for the info. I tried googling for this relatively hard, couldn't find that bug. Language on that bug is probably counterproductive, but other than that, some reasonably sensible way should exist to simply stop logging crap, not relying on just output filtering. What you see are authpriv-level logs, so it would be a really bad idea to suppress them, regardless of their source. Currently, journald doesn't provide any means of log processing, so your only choice is to filter logs when viewing them using journalctl command line or grep/awk; you can not control what is logged when and where. If you want log processing (multiple log directories, advanced filtering, etc.), use syslog-ng or rsyslog. For example, one can setup a special logfile for systemd-related messages with a given syslog facility (authpriv, daemon, etc.). HTH, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpERrsRV4Zx0.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
On Mon, Jun 09, 2014 at 07:57:29AM +, Rusty Bird wrote: Date: Mon, 09 Jun 2014 07:57:29 + From: Rusty Bird rustyb...@openmailbox.org To: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks Hi Leonid, On Sun, Jun 08, 2014 at 12:33:44PM +, Rusty Bird wrote: Adding to Djalal's and Mantas's examples, the systemd host may also be a gateway with its firewall configured to forward only *some* packets. If systemd itself is a server (you mean journald really, yes?) systemd host = The machine that systemd runs on In the example, this machine is a gateway/router, so it's the Linux kernel (not systemd itself or any service) that receives packets from other machines in your network and forwards them towards their destination. how can I protect the machine with yet another target? Why there is no way to tell systemd directly to start listening only after network.target is up? On a related note, what do you do about things like sshd.socket (or crap like cups.socket) which are not ordered against anything network-related? network-pre.target is intended to block the initial configuration of the network interfaces (your Ethernet card, your WiFi radio) so that it doesn't matter what software component is listening for, or trying to send, packets: The machine remains cut off from all* network links until the firewall initialization succeeds. * Except, if you bring up a network interface during early boot, e.g. using the kernel parameter ip= or an initramfs. In that case, it's your own responsibility to bring it down before systemd takes over. If you care about leaks. Cool. I see your point now. Thanks, Leonid. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpM1WBQnbBym.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On Mon, Jun 09, 2014 at 08:08:43PM +0200, Reindl Harald wrote:
Date: Mon, 09 Jun 2014 20:08:43 +0200
From: Reindl Harald h.rei...@thelounge.net
To: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] How to quiet cron sessions logging with
systemd-212?
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
Thunderbird/24.5.0
Am 09.06.2014 17:28, schrieb Leonid Isaev:
On Mon, Jun 09, 2014 at 10:48:31AM +0300, Leho Kraav wrote:
Date: Mon, 09 Jun 2014 10:48:31 +0300
From: Leho Kraav l...@kraav.com
To: Reindl Harald h.rei...@thelounge.net,
systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] How to quiet cron sessions logging with
systemd-212?
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
Thunderbird/24.5.0
On 09.06.2014 10:43, Reindl Harald wrote:
nobody cares because the developers point of view is that what is
interesting for them needs to be also faced by the sysadmin
otherwise this would be only logged in debug-mode and bugreports
not closed: https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c3
frankly if that messages would at least have a prefix or a different
process than systemd one could filter them out with rsyslog.conf
without supress relevant boot messages
Thanks for the info. I tried googling for this relatively hard, couldn't
find that bug.
Language on that bug is probably counterproductive, but other than that,
some reasonably sensible way should exist to simply stop logging crap, not
relying on just output filtering.
What you see are authpriv-level logs, so it would be a really bad idea to
suppress them, regardless of their source
no user needs them, there are already logs which command was
started for which user from crond with just 3 lines
If you don't need them -- OK, but don't speak for the others. Why systemd
should be treated any differently than other programs? If it generates authpriv
messages -- they should be collected, not ignored. What about normal, i.e.
user-initiated logins -- should they be logged?
Jun 9 19:01:01 rawhide CROND[1696]: (root) CMD (run-parts /etc/cron.hourly)
Jun 9 19:01:01 rawhide run-parts[1696]: (/etc/cron.hourly) starting 0anacron
Jun 9 19:01:01 rawhide run-parts[1705]: (/etc/cron.hourly) finished 0anacron
Jun 9 20:01:01 rawhide CROND[1735]: (root) CMD (run-parts /etc/cron.hourly)
Jun 9 20:01:01 rawhide run-parts[1735]: (/etc/cron.hourly) starting 0anacron
Jun 9 20:01:01 rawhide run-parts[1744]: (/etc/cron.hourly) finished 0anacron
they are introduced in that floody way with recent systemd
all the decades before crond did run fine, logs exactly what
you need to know if /var/log/secure and /var/log/crond
without writing *hundret thousands* loglines all day long
on machines with a lot of cronjobs
But why can't you write a syslog filter which uses facility as well as program
name? So if you believe that systemd-generated messages are useless, drop them,
or store them in a volatile location like /run/log. Something like this (in
syslog-ng language):
---
destination d_systemd { file(/run/log/systemd.log); };
filter f_daemon { facility(daemon) and not level(debug) and not \
program(systemd); };
filter f_systemd { program(systemd); };
log { source(src); filter(f_systemd); destination(d_systemd); };
---
--
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4
C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
pgpz5kfVKZuoL.pgp
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On Mon, Jun 09, 2014 at 09:19:20PM +0200, Reindl Harald wrote: [...] on our production infrastrcuture these messages would be *a lot* more than all other logs summarized *and* they are spitted to /var/log/messages to make things worst But why can't you write a syslog filter which uses facility as well as program name? So if you believe that systemd-generated messages are useless, drop them because you *can not* distinguish between *that* user messages and system message sbecause they have systemd as program name common, the PID changes and you don't want to drop *system messages* from systemd So, systemd starts certain things on _any_ user login: be it a real user, or a daemon. However, if you already have logs from the daemon (cron) or a login program (login), why keep systemd-generated messages? I'd put them in a separate file... if they would contain a unique string / prefix to distinguish Do you have something concrete in mind? from cronjobs triggered messages i would have written a rsyslog filter as for a lot of other noise long ago however - the *large amount* of that messages even if you drop them consumes useless ressources on virtualization clusters and blow up the systemd-journal If resources are an issue, don't use the journal. In my experience, it consumes ~4x space compared to syslog (on a firewall machine, after 2 months uptime)... -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpkW9mGeOXcS.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
Hi, On Sun, Jun 08, 2014 at 12:33:44PM +, Rusty Bird wrote: Date: Sun, 08 Jun 2014 12:33:44 + From: Rusty Bird rustyb...@openmailbox.org To: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks Leonid Isaev: But by the time network.target is reached there are no listening services yet, are there? So, why would one need a firewall? Adding to Djalal's and Mantas's examples, the systemd host may also be a gateway with its firewall configured to forward only *some* packets. Rusty Thanks for an explanation, but this is exactly what I don't understand. But please note, that I agree with you that firewall must be enabled as early as possible during boot... If systemd itself is a server (you mean journald really, yes?), how can I protect the machine with yet another target? Why there is no way to tell systemd directly to start listening only after network.target is up? On a related note, what do you do about things like sshd.socket (or crap like cups.socket) which are not ordered against anything network-related? Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpXEGuY4qxtS.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
On Sun, Jun 08, 2014 at 01:07:38AM +0200, Zbigniew Jędrzejewski-Szmek wrote: Date: Sun, 8 Jun 2014 01:07:38 +0200 From: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl To: Michael Biebl mbi...@gmail.com Cc: systemd Mailing List systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks User-Agent: Mutt/1.5.20 (2009-06-14) On Sun, Jun 08, 2014 at 12:55:55AM +0200, Michael Biebl wrote: Could you elaborate why Before=network.target is too late? Because then network setup races with e.g. iptables setup. Depending on the timing, a window in which the network has been set up, but the firewall is not yet in place. But by the time network.target is reached there are no listening services yet, are there? So, why would one need a firewall? Thanks, Leonid. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpxmHWBdpNa1.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Disable IPv6?
On Sun, Jun 08, 2014 at 09:16:43AM +0800, Aaron Lewis wrote: Date: Sun, 8 Jun 2014 09:16:43 +0800 From: Aaron Lewis the.warl0ck.1...@gmail.com To: systemd-devel@lists.freedesktop.org Subject: [systemd-devel] Disable IPv6? Hi, Every time I boot I can see a 'failed to insert ipv6 module' message, pretty annoying I want to disable IPv6 service, is that possible? For the record, I disabled IPv6 intentionally in my customized kernel See https://bugs.archlinux.org/task/38661 . My suggestion would be to either compile a kernel with CONFIG_IPV6=y and then use ipv6.disable=1 in the kernel cmdline (that's what I do), or build ipv6 as a module and blacklist it via modprobe.conf -- Best Regards, Aaron Lewis - PGP: 0x13714D33 - http://pgp.mit.edu/ Finger Print: 9F67 391B B770 8FF6 99DC D92D 87F6 2602 1371 4D33 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpth3iLounnB.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-networkd, default route and multiple interfaces
Hi, On 06/06, Lennart Poettering wrote: Date: Fri, 6 Jun 2014 15:43:21 +0200 From: Lennart Poettering lenn...@poettering.net To: Mantas Mikulėnas graw...@gmail.com Cc: systemd Mailing List systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] Systemd-networkd, default route and multiple interfaces User-Agent: Leviathan/19.8.0 [zh] (Cray 3; I; Solaris 4.711; Console) On Wed, 04.06.14 00:29, Mantas Mikulėnas (graw...@gmail.com) wrote: On Tue, Jun 3, 2014 at 9:58 PM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 02.06.14 21:02, Tom Gundersen (t...@jklm.no) wrote: On Mon, Jun 2, 2014 at 8:47 PM, Reventlov contact+systemd...@volcanis.me wrote: Since network files are applied to links whenever the links appear, how do systemd manage the disappearance of a default route ? You can have several default routes, so we just configure them all and let the kernel handle it for us. We probably should improve the config options to make it possible to override the priority of the routes. Windows initializes the route metric value for each route from the speed of the interface. If there are multiple links and for one we know it's a gigabit ethernet link, and the other is a 54mbit wlan link, then the former would automatically get preference... it's a bit black magic, but kinda cool black magic i think... that said, i am not sure we even have a sane API to determine the speed of links... maybe ethtool reports it at least for wired ethernet? but for wlan? Both `iwconfig dev` and `iw dev link` report the link speed (one using the old wext and the other nl80211, I think?). No idea about all the other link types that Linux supports though. As long as we'd only have to check ethtool for wired ethernet and the wireless stack for wireless ethernet and can cover 70% of all devices with that, this sounds like the right thing to do for me... Note, however, that wlan link speed can fluctuate in time. At least that's what happens with eduroam at our university (mostly cisco APs). Also, when comparing wlan and eth link speeds, does one take into account the different overheads due to frames, encryption, etc., or just compare bare speeds? Cheers, Leonid. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpOvtKxyZwK3.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Archlinux setup WLAN-Problems
On Sat, 31 May 2014 17:27:11 +0200 Lucas Thieme l...@thiemeonline.de wrote: configurated correct in/etc/rc.conf, and I thought, systemd replaced it. Yes, more than a year ago... Anyway, this is a wrong mailing list for your question. Go to bbs.archlinux.org and ask on the forums. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How do I disable rfkill1 service? I only have slot 0 and 2
On Wed, 28 May 2014 11:55:08 +0400 Kirill Elagin kirela...@gmail.com wrote: Might be that rfkill1 disappears after rfkill0 is switched off, if they are related. Right. Additionally, on my system one rfkill? controls multiple devices. This is why I suggested disabling systemd state-storing at all: it works OK in simple cases, but is meaningless and breaks things on tricky hardware. -- Кирилл Елагин Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How do I disable rfkill1 service? I only have slot 0 and 2
Hi, On Wed, 28 May 2014 08:25:52 +0800 Aaron Lewis the.warl0ck.1...@gmail.com wrote: Hi, I'm running Arch and recently upgraded system, now every time I boot I see a dead service: rfkill1 systemd-rfkill@rfkill0.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill0 ● systemd-rfkill@rfkill1.service loaded failed failedLoad/Save RF Kill Switch Status of rfkill1 systemd-rfkill@rfkill2.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill2 I tried to run `systemctl disable systemd-rfkill@rfkill1`, but there's no output after that and it wasn't disabled at all Any ideas? Yes: systemctl mask systemd-rfkill@rfkill1.service. Or better yet, append systemd.restore_state=0 to your kernel cmdline. Cheers, L. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Delaying (SSH) key generation until the urandom pool is initialized
Hi Florian, Let me see if I understand you... First, where did you get the logs from: syslog or journald? On Wed, 30 Apr 2014 14:02:11 +0200 Florian Weimer fwei...@redhat.com wrote: [...] Using /dev/urandom for key generation is fine once its pool is seeded. Are you concerned that the PRNG is not seeded properly and hence the keys are cryptographically weak? I thought that openssh uses openssl which in turn has its own PRNG that is seeded from /dev/random and /dev/urandom. Using existing key generation algorithms with /dev/random instead does not work because they consume too much entropy and can block for significantly more time than just a few minutes. Entropy is not a problem if you run a daemon like haveged. Indeed, archlinux iso images provide a service which generate 2048 bit gpg keys (for package signing) on each boot with no delay (and gpg uses /dev/random). Moreover, I run ssh-keygen on-boot to generate a volatile key for the root account, and the order of services appears to be correct (taken from journal -o verbose): 11:46:15.252713 CDT -- random: nonblocking pool is initialized 11:46:15.970371 CDT -- haveged is operational 11:46:17.576259 CDT -- ssh-keygen exits Cheers, L. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent timers delay Type=idle units
Hi, On Wed, 23 Apr 2014 05:57:39 +0200 Lennart Poettering lenn...@poettering.net wrote: [...] Ah, OK, I think I got it now: You have services that are to be started by timers that take a long time to complete. THe timers have been configured to be persistent. If the system comes up and the timestamp files suggest that the timers need to be triggered immediately this is done, adding the service execution time to the bootup time. This is normally not a problem except when there's some other bootup service that uses Type=idle which will then be affected by these long running services... Did I get this right? Yes. Of course, the meaning of long really depends... but it can be ~10 sec. Hmm, this sounds nasty. I wodner what we can do about it... Maybe we should add a new setting PersistentExtraSec= to timer units or so which allows delaying these kind of timers by an extra margin. Would this work for you? Yes, I think so. Actually, that's what Thomas proposed on arch-general... What does systemctl list-jobs print when this happens? (i.e. when the bootup is supposedly delayed?) I'll have to test this, but I'll speculate that list-jobs will show nothing by the time I login, because it takes about 30 sec for me to enter login credentials... Use systemctl enable debug-shell... OK will do. I didn't know about the debug shell. Thanks, L. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent timers delay Type=idle units
Hi, I'll try to answer all questions at once... On Tue, 22 Apr 2014 09:37:29 +0200 Thomas Bächler tho...@archlinux.org wrote: Am 22.04.2014 07:07, schrieb Lennart Poettering: Humm? What precisely do you mean by delays bootup? Just scheduling a timer unit should have about zero effect on boot times... If it does this would be a bug. This is right for the usual, e.g. OnBootSec= timers. Just to give a little background, archlinux has recently replaced daily cron jobs (like indexing of man and locate databases) with OnCalendar= timers: https://mailman.archlinux.org/pipermail/arch-dev-public/2014-March/026044.html . From the description that I linked in the first post, it seems that the unit it started as soon as the timer is started. I don't know if delay bootup is the right expression, but the Type=idle units, like getty, don't start until the timer's unit finished starting up. Right. I see no delay between scheduling an OnCalendar= timer and starting the corresponding service. This wouldn't be a problem in general, but if the /var/lib/systemd/stamp-... file is old enough, the timer and service are launched at boot. However, the latter usually takes some time to start. Ideally, one would like to specify the above delay in the .timer file, because services started by the OnCalendar timers are sometimes maintainance jobs and not always needed for booting the system. What does systemctl list-jobs print when this happens? (i.e. when the bootup is supposedly delayed?) I'll have to test this, but I'll speculate that list-jobs will show nothing by the time I login, because it takes about 30 sec for me to enter login credentials... Thanks, L. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] LXC not working with systemd 209 or later
Hi, On Sat, 05 Apr 2014 22:04:05 +0100 John Lane syst...@jelmail.com wrote: [...] Ok, now this is wierd. I have distilled the problem down to the bare bones. I have a build_container script (http://pastebin.com/raw.php?i=RhDFhRZi) that will create a container called testcontainer. It exhibits the problems I see. Now, if I rename that container to, say testc, and restart it (changing nothing else at all) then it works fine. I am totally confused but it appears that the container's name affects how systemd operates...? It is not the name but special characters in it -- is there anything wierd about your locale, etc. settings? if you can try it and see if the same happens to you that would be very helpful. $ ./build_container $ lxc-start -n testcontainer it starts: will see journal output in the console boot messages, like this: 30systemd[1]: Set hostname to test. you can log in as root. no password. Long delay. Eventual user@0.service start operation timed out. Terminating You can then halt. slow to stop. user@0.service start operation timed out. Terminating takes 90 seconds. Eventually stops, host prompt returned. I ran your script in a freshly installed archlinux x86_64 VM and couldn't reproduce what you are seeing, regardless of how I call the container... [...] Actually, you can avoid the above. Here's another test with just lxc-create $ lxc-create -n testcontainer -t archlinux -- -P util-linux $ lxc-start -n testcontainer Same problem. Same as above, no problem. Cheers, -- Leonid Isaev GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Masking .network files
Hi,
On Sat, 5 Apr 2014 11:26:17 +0200
Tom Gundersen t...@jklm.no wrote:
On Sat, Apr 5, 2014 at 12:43 AM, Leonid Isaev lis...@umail.iu.edu wrote:
I seem to have a strange issue with the way networkd processes its
configuration files. The machine is actually a systemd-nspawn container
with a static IP address, so I had to mask the default
80-container-host0.network and create a custom config. Both real and
virtual machines are up-to-date archlinux [testing] installations.
So the best way to do this is to name your custom config file either
the same as what you are overriding (if the overridden file should
anyway never be used, which is the case for what you describe), or
simply name it starting with a lower number. That way the first
matching file will be applied.
Thanks for the explanation.
I figured that much, just wanted to know whether it was a 'feature'.
The 'masking' logic that you know from unit files does not really make
much sense for .network files (but maybe this is something we should
change...). Symlinks to /dev/null are just treated as empty .network
files, so their meaning is no [Match] section, which matches
everything and no [Network] section, which does nothing.
I don't know the grand goal of networkd, so it's just an opinion, but it seems
odd that the daemon will touch interfaces it shouldn't just because there is a
masked .network file (what if I want a given iface to stay down after boot).
I suppose
this may be used to express ignore any subsequent .network files,
but I doubt that is a particularly useful thing to do.
Wouldn't this be a bad thing? Because a distribution/upstream can break lots
of boxes by providing e.g. /usr/lib/systemd/network/30-stupid-default.network
which most people will automatically (and naively) mask...
Best,
L.
-
$ file /{etc,usr/lib}/systemd/network/80-container-host0.network
/etc/systemd/network/80-container-host0.network: symbolic link to
`/dev/null' /usr/lib/systemd/network/80-container-host0.network: ASCII text
$ cat /etc/systemd/network/eth.network
[Match]
Name=host0
[Network]
Address=10.137.0.2/24
Gateway=10.137.0.1
[DHCPv4]
UseDNS=false
-
However, this new .network file is never picked up by systemd-networkd (it
does provide a working network setup if the host0 interface is renamed).
Here is the debug output:
-
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: timestamp of
'/etc/systemd/network' changed
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: timestamp of
'/run/systemd/network' changed
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: Skipping overridden
file: /usr/lib/systemd/network/80-container-host0.network.
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: Configuration
file /etc/systemd/network/80-container-host0.network is marked
world-writable. Please remove world writability permission bits.
Proceeding anyway. Apr 04 21:29:00 lxc_archtest systemd-networkd[128]:
host0: found matching network
'/etc/systemd/network/80-container-host0.network' Apr 04 21:29:00
lxc_archtest systemd-networkd[128]: host0: requesting link status
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: bringing link up
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: link configured
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: link (with
ifindex 22) added
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: found matching
network '/etc/systemd/network/80-container-host0.network'
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: requesting link
status Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: bringing
link up Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: link
configured Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: link
(with ifindex 1) added
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: MAC address:
36:9a:b1:98:ab:e1
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: link status
updated: - 0x00011043
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: link is up
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: carrier on
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: Sent message
type=method_call sender=n/a destination=org.freedesktop.DBus
object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello
cookie=1 reply_cookie=0 error=n/a Apr 04 21:29:00 lxc_archtest
systemd-networkd[128]: Got message type=method_return
sender=org.freedesktop.DBus destination=:1.8 object=n/a interface=n/a
member=n/a cookie=1 reply_cookie=1 error=n/a Apr 04 21:29:00 lxc_archtest
systemd-networkd[128]: lo: link status updated: - 0x00010049 Apr
04 21:29:00 lxc_archtest systemd-networkd[128]: lo: link is up Apr 04
21:29:00 lxc_archtest systemd-networkd[128]: lo: carrier on Apr 04
21:29:00 lxc_archtest systemd-networkd[128]: Got message type=signal
sender
Re: [systemd-devel] Masking .network files
On Sun, 6 Apr 2014 01:12:45 +0200 Tom Gundersen t...@jklm.no wrote: So in general masking .network files (in the sense applied to unit files) does not make much sense, and will probably not behave as you would expect from knowing unit files. We may very well want to change this in networkd, but need to think a bit about precisely how (the whole logic is quite different from unit files, so copying the same behavior doesn't quite work I think). My question is much simpler: why are empty .network files and files with an empty [Match] section treated equally? Clearly, empty files still do something. AFAIU networkd compiles a list of all .network units before applying their settings, so one can check that a file is empty and kick it off the list, no? But please note that I haven't looked at the code in detail, so feel free to ignore me if the above makes no sense. Best, L. -- Leonid Isaev GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] LXC not working with systemd 209 or later
On Fri, 04 Apr 2014 21:19:45 +0100 John Lane syst...@jelmail.com wrote: [...] I did this: systemd-nspawn -bD /srv/lxc/testcontainer Starting the container this way is pretty-much instantaneous. You can log in and halt it cleanly. Now that's interesting... 3. How do you mount API filesystems into the container (your config doesn't have /sys and /proc entries)? Try putting the fstab generated by the archlinux template (because that one I tested and it works). AIUI systemd does this automatically. They are mounted in my container. # df /proc /proc/sys /sys Filesystem 1K-blocks Used Available Use% Mounted on proc 0 0 0- /proc proc 0 0 0- /proc sysfs 0 0 0- /sys You are right, a container can be run without any lxc.mount entries at all. However, FYI, the following works and gives verbose logging output. lxc-start -n testcontainer /usr/lib/systemd/systemd -- --log-target=console --log-level=debug ... which is? I am now at the point where I have 2 containers, one created by lxc-archlinux (which works) and one created using what I believe are similar equivalent steps. They both have the exact same lxc config and the exact same packages installed. I still have the problem, but I have discovered more info... I get user@0.service start operation timed out. Terminating. I tried to execute systemd --user manually and got Trying to run as user instance, but $XDG_RUNTIME_DIR is not set. I've been digging around and noticed in the journal: Failed to open private bus connection: Failed to connect to socket /run/user/0/dbus/user_bus_socket: No such file or directory and pam_systemd(login:session): Failed to create session: Connection timed out I believe the problem lies in pam_systemd timing out (hence the login delay) because it can't talk to systemd-logind due to some IPC problem that I can't work out yet... It's difficult to say what's going on without a verbose journal output... Can you obtain one? Can you post your container creation scripts, so that I try to reproduce your issue over the weekend? Also, what's the answer to Tom's question? Cheers, -- Leonid Isaev GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Masking .network files
Hi,
I seem to have a strange issue with the way networkd processes its
configuration files. The machine is actually a systemd-nspawn container with
a static IP address, so I had to mask the default 80-container-host0.network
and create a custom config. Both real and virtual machines are up-to-date
archlinux [testing] installations.
-
$ file /{etc,usr/lib}/systemd/network/80-container-host0.network
/etc/systemd/network/80-container-host0.network: symbolic link to `/dev/null'
/usr/lib/systemd/network/80-container-host0.network: ASCII text
$ cat /etc/systemd/network/eth.network
[Match]
Name=host0
[Network]
Address=10.137.0.2/24
Gateway=10.137.0.1
[DHCPv4]
UseDNS=false
-
However, this new .network file is never picked up by systemd-networkd (it
does provide a working network setup if the host0 interface is renamed). Here
is the debug output:
-
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: timestamp of
'/etc/systemd/network' changed
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: timestamp of
'/run/systemd/network' changed
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: Skipping overridden
file: /usr/lib/systemd/network/80-container-host0.network.
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: Configuration
file /etc/systemd/network/80-container-host0.network is marked world-writable.
Please remove world writability permission bits. Proceeding anyway.
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: found matching
network '/etc/systemd/network/80-container-host0.network'
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: requesting link
status
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: bringing link up
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: link configured
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: link (with ifindex
22) added
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: found matching network
'/etc/systemd/network/80-container-host0.network'
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: requesting link status
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: bringing link up
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: link configured
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: link (with ifindex 1)
added
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: MAC address:
36:9a:b1:98:ab:e1
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: link status
updated: - 0x00011043
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: link is up
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: carrier on
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: Sent message
type=method_call sender=n/a destination=org.freedesktop.DBus
object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello
cookie=1 reply_cookie=0 error=n/a
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: Got message
type=method_return sender=org.freedesktop.DBus destination=:1.8 object=n/a
interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: link status updated:
- 0x00010049
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: link is up
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: carrier on
Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: Got message type=signal
sender=org.freedesktop.DBus destination=:1.8 object=/org/freedesktop/DBus
interface=org.freedesktop.DBus member=NameAcquired cookie=2 reply_cookie=0
error=n/a
Apr 04 21:29:02 lxc_archtest systemd-networkd[128]: Received SIGINT.
Apr 04 21:29:02 lxc_archtest systemd-networkd[128]: Assertion
's-event-state != SD_EVENT_FINISHED' failed at
src/libsystemd/sd-event/sd-event.c:1308, function
sd_event_source_set_enabled(). Ignoring.
Apr 04 21:29:02 lxc_archtest systemd-networkd[128]: Assertion
's-event-state != SD_EVENT_FINISHED' failed at
src/libsystemd/sd-event/sd-event.c:1308, function
sd_event_source_set_enabled(). Ignoring.
Apr 04 21:29:02 lxc_archtest systemd-networkd[128]: Assertion
's-event-state != SD_EVENT_FINISHED' failed at
src/libsystemd/sd-event/sd-event.c:1308, function
sd_event_source_set_enabled(). Ignoring.
-
I understand that the 1st matching configuration is applied but why does it
concern overriden files? Also, why does a symlink to /dev/null match all
interfaces (even loopback)?
Thanks,
--
Leonid Isaev
GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] LXC not working with systemd 209 or later
Hi, On Thu, 03 Apr 2014 11:25:27 +0100 John Lane syst...@jelmail.com wrote: Hello, I have a number of LXC containers that have been working with systemd for some time. I have just tried to perform some upgrades, taking them from 204 to 212 (actually they are scripted rebuilds rather than upgrades). You have to tell exactly what you are doing. Just calling lxc-archlinux in a loop? I have found that they do not work properly with any systemd versions 209 or later. I have read that 209 was a massive new release. What do you mean by do not work properly? Also, FWIW: Host: -hermes-11:37-cur_work$ systemctl --version systemd 212 +PAM -AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP -APPARMOR Container: [appuser@appserver1 ~]$ systemd-detect-virt lxc [appuser@appserver1 ~]$ uname -a Linux appserver1 3.13.8-1-ARCH #1 SMP PREEMPT Tue Apr 1 12:19:51 CEST 2014 x86_64 GNU/Linux [appuser@appserver1 ~]$ systemctl --version systemd 212 +PAM -AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP -APPARMOR [appuser@appserver1 ~]$ journalctl PRIORITY=3 -- Logs begin at Thu 2014-04-03 10:24:09 EDT, end at Thu 2014-04-03 11:27:50 EDT [appuser@appserver1 ~]$ journalctl PRIORITY=4 -- Logs begin at Thu 2014-04-03 10:24:09 EDT, end at Thu 2014-04-03 11:27:50 EDT Cheers, -- Leonid Isaev GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] LXC not working with systemd 209 or later
On Thu, 03 Apr 2014 18:53:48 +0100 John Lane syst...@jelmail.com wrote: On 03/04/14 16:40, Leonid Isaev wrote: Hi, On Thu, 03 Apr 2014 11:25:27 +0100 John Lane syst...@jelmail.com wrote: Hello, I have a number of LXC containers that have been working with systemd for some time. I have just tried to perform some upgrades, taking them from 204 to 212 (actually they are scripted rebuilds rather than upgrades). You have to tell exactly what you are doing. Just calling lxc-archlinux in a loop? I am not sure what you mean by Just calling lxc-archlinux in a loop. I build a container using a script that is similar to, but not the lxc-archlinux template. It uses the Arch tools mkarchroot and pacman to install a collection of packages and then performs various setup tasks and creates appropriate configuration. Here is the LXC config produced: # Use autodev to be compatible with systemd lxc.autodev = 1 lxc.hook.autodev = /srv/lxc/testcontainer/autodev # hostname lxc.utsname = testcontainer # # network # if the network is not defined then the container # will be able to use the host's network lxc.network.type = veth #lxc.network.flags = up lxc.network.link = br0 lxc.network.name = eth0 lxc.network.mtu = 1500 lxc.network.hwaddr = DE:AD:BE:EF:CA:FE # restrict capabilities (security) see man capabilities lxc.cap.drop = sys_module #lxc.cap.drop = sys_admin # only explicit device access lxc.cgroup.devices.deny = a # # Memory Devices lxc.cgroup.devices.allow = c 1:3 rwm lxc.cgroup.devices.allow = c 1:5 rwm lxc.cgroup.devices.allow = c 1:7 rwm lxc.cgroup.devices.allow = c 1:8 rwm lxc.cgroup.devices.allow = c 1:9 rwm # # Terminals lxc.tty = 1 lxc.pts = 1024 lxc.cgroup.devices.allow = c 4:0 rwm lxc.cgroup.devices.allow = c 5:0 rwm lxc.cgroup.devices.allow = c 5:1 rwm lxc.cgroup.devices.allow = c 5:2 rwm lxc.cgroup.devices.allow = c 136:* rwm # # root filesystem lxc.rootfs = /srv/lxc/testcontainer # bind mount the host's pacman cache so container uses the same cache # rather than wasting time downloading packages already downloaded. lxc.mount.entry = /var/cache/pacman/pkg /srv/lxc/testcontainer/var/cache/pacman/pkg none rw,bind 0 0 This works fine with 208 but not with 209 so, I guess I am doing something that was correct for 208 but the goal-posts have been moved by 209. Well, few obvious questions: 1. Have you tried booting and logging in the container with systemd-nspawn? Also, look at the --link-journal option for log debugging. 2. What does the autodev hook do and why do you need it? 3. How do you mount API filesystems into the container (your config doesn't have /sys and /proc entries)? Try putting the fstab generated by the archlinux template (because that one I tested and it works). 4. AFAIU, lxc-start calls /sbin/init (which points to systemd). I'm not sure if this will work, but try replacing container init with a script that calls systemd --log-target=console --log-level=debug... I have found that they do not work properly with any systemd versions 209 or later. I have read that 209 was a massive new release. What do you mean by do not work properly? What I find is that the login prompt never results in a prompt. I enter the correct user/password and it takes an age before redisplaying the login prompt. If apply 208 before starting the container then it works as expected. I can get into the container with lxc-attach. I'm a bit in the dark as the journal isn't showing me anything (or I don't know where to look). The thing I did notice was the 209 journal contained less than the 208 one which would suggest that 209 is not starting some services that 208 does (see linked pastes). I am looking into that but was hoping there might be an obvious pointer from the list - some things that have changed in 209 that might affect LXC and that I could perhaps look into more. I am not sure that this particular issue is systemd's fault because I just created a working container on a fresh/stock arch install (with community/lxc) using the template (to test the patches which I sent to lxc-devel). HTH, -- Leonid Isaev GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] run systemd-tmpfiles-clean only when we have AC power
On Thu, 3 Apr 2014 21:26:23 +0200 Tomasz Torcz to...@pipebreaker.pl wrote: On Thu, Apr 03, 2014 at 03:42:08PM -0300, Cristian Rodríguez wrote: While it is cool to be neat and clean all the time, this task can wait if we are on battery. What if I connect my laptop to AC only when it sleeps? This will never run. I agree that cleaning /tmp and /run is a low-priority task, but what if there are custom *.conf files in /etc/tmpfiles.d? AFAIU, these will not be run as well, but may be needed. And in the past, the difference in AC-powered and BAT-powered behavior in pm-utils and Upower has created _lots_ of confusion. I also don't think couple stats() and rm's have any measurable impact on battery. Stock tmpfiles.d clean routine applies only to tmpfs (by default) filesystems. On a battery-powered system, they are most likely clean due to small uptime. -- Leonid Isaev GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Mount options for $XDG_RUNTIME_DIR
Hi Dave, On Tue, 18 Mar 2014 13:29:36 -0400 Dave Reisner d...@falconindy.com wrote: [...] Moreover noexec is mostly snake-oil, isn't it? You can invoke the executables with an interpreter still, and you can copy the files elsewhere... True for the interpreted code. And compiled code. The linker is your ELF interpreter. Sorry if this is off-topic, but how do you that? With /lib/ld-2.19.so /path/to/executable? Thanks, -- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Mount options for $XDG_RUNTIME_DIR
[Sorry, forgot to CC the mailing list] Hi Lennart, On Tue, 18 Mar 2014 02:33:50 +0100 Lennart Poettering lenn...@poettering.net wrote: On Mon, 17.03.14 19:04, Leonid Isaev (lis...@umail.iu.edu) wrote: Hi, Currently, XDG_RUNTIME_DIR=/run/user/UID is mounted with rather permissive, hardcoded mount options (or at least I couldn't find a documented way of changing them). Specifically, a user is allowed to execute things from his $XDG_RUNTIME_DIR. This effectively negates admin's ability to constrain users, e.g. by mounting /home as noexec (I have seen this done in some environments). Is there a need to allow execution from $XDG_RUNTIME_DIR? And how should one configure its mount options? Yes, this is hardcoded in 211, that's true. We could make this configurable but I am not really convinced that we really want that? I agree that a complete, fstab-like configuration may be too much. I mean, the XDG_RUNTIME_DIR spec says the dir must be fully-featured by the standards of the operating system. More specifically, ... proper permissions ... must be supported. I'd read that as if the x bit should do what it is supposed to do. So, in order to stay compatible with the spec allowing to mount it with noexec sounds undesirable. Well, regardless of what the XDG specification says, the fact is that currently each user has 2 /home's: one under the admin control, another -- not. Of course, one could hook into PAM and remount each user's XDG_RUNTIME_DIR upon login, but this is hacking around the init system... What about making XDG_RUNTIME_DIR inherit mount options from /home if the latter is a separate partition and fall back to the current default otherwise? Moreover noexec is mostly snake-oil, isn't it? You can invoke the executables with an interpreter still, and you can copy the files elsewhere... True for the interpreted code. However regarding other places, if an admin cares about noexec at all, /var/tmp, /tmp and /dev/shm should be also constrained (I am not saying that this should be the default, just configurable). Thanks, Leonid. Note that setting noexec on an fs means you cannot maps its files PROT_EXEC anymore, which breaks a number of things. In the past people attempted to mount /dev/shm as noexec, and dosemu broke because it made use of this. Then people wanted to mount /dev as noexec, which broke X11 which wanted to map some device nodes PROT_EXEC. Given that we consider XDG_RUNTIME_DIR as a private version of /dev/shm among other things it really sounds wrong to break this right from the start. So, I am not really convinced I must say... Lennart -- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Mount options for $XDG_RUNTIME_DIR
Hi, Currently, XDG_RUNTIME_DIR=/run/user/UID is mounted with rather permissive, hardcoded mount options (or at least I couldn't find a documented way of changing them). Specifically, a user is allowed to execute things from his $XDG_RUNTIME_DIR. This effectively negates admin's ability to constrain users, e.g. by mounting /home as noexec (I have seen this done in some environments). Is there a need to allow execution from $XDG_RUNTIME_DIR? And how should one configure its mount options? Thanks, -- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
