Re: [systemd-devel] howto switch from grub2-bios to systemd-boot
On Sat, Sep 5, 2020 at 3:12 AM Lennart Poettering wrote: > > On Fr, 04.09.20 21:41, Dave Howorth (syst...@howorth.org.uk) wrote: > > > On Fri, 4 Sep 2020 17:44:23 +0200 > > Lennart Poettering wrote: > > > On Fr, 04.09.20 17:10, Reindl Harald (h.rei...@thelounge.net) wrote: > > > > > > > > No, that's not supported in sd-boot. A boot loader is a boot > > > > > loader, it should contain a fragile storage stack. It's kinda > > > > > what sd-boot is supposed to do better than grub. > > > > > > > > well, a boot loader should just *load* and not write anything so > > > > RAID1 is technically no problem and it shouldn't matter which of > > > > the 1, 2, 3 or 4 disks is there unless one survived. > > > > > > Robust boot loaders typically want to write boot counters to disk, so > > > that they can automatically revert back to older versions of the > > > OS/kernel if it doesn't boot. Thus some form of write access is > > > necessary if you care about robustness. > > > > But surely a boot loader of all things should never try to write to the > > place it is loading from? Booting should be idempotent (as long as it > > works, for sure). The only sane policy would seem to be that the loader > > had another path to a separate writable area? > > UEFI provides file system access. Both read and write. Typically for > VFAT. Yeah, a boot loader should not modify the files it is itself > loaded from and also keep writes generally at a minimum, but counting > boots is generally the absolute minimum necessary, and can be > implemented by single sector updates in file systems such as VFAT. So > that's what sd-boot for example does. May I know why this design has been chosen over keeping the boot counts in UEFI variables? -- Alexander E. Patrakov CV: http://pc.cd/PLz7 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] _netdev for system root mount?
On Fri, Mar 13, 2020 at 7:07 PM Andrei Borzenkov wrote: > And what is the "official" way to prevent various units required by root > mount from being stopped during shutdown? There could be arbitrarily > deep stack (NIC - iSCSI - multipath - raid - lvm - crypto - ...). https://systemd.io/ROOT_STORAGE_DAEMONS/ -- Alexander E. Patrakov CV: http://pc.cd/PLz7 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] homed, LUKS2 passphrase encoding, and recovery key
On Fri, Jan 24, 2020 at 2:11 AM Chris Murphy wrote: > > Thanks for the answer, it's very useful. When I asked the question, I > didn't fully appreciate the cryptographic and anti-forensic > capabilities in LUKS that almost certainly should not be > re-implemented elsewhere. > > I'd like to better understand what it would take to support UTF-8 > passphrases for LUKS (luksFormat, luksOpen). Consistently and > reliably, in a portable user home context. Of course the keyboard > could change. Locale could, thus default local language of the host > system could be different. I think there is a very important thing missing in your email: analysis what works and what doesn't work in the context of non-Linux operating systems. > That's the short version. Everything below this line is a super > verbose explanation how I'm arriving at the above. > > I assume users want their login passphrase to use local characters. That's just an assumption, with no data presented to back it up. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
пт, 27 сент. 2019 г. в 16:50, Lennart Poettering : > > 1. full disk encryption with the user typing in the password on the >kbd. But isn't the answer to this to link the root OS to the tpm >instead, and use user-keyed crypto only for $HOME? The OS itself >doesn't need to be protected after all, everbody should have the >same files there anyway, it's $HOME that needs protection. > It is still hard (due to the old, now expired, self-embargo) to buy any PC with a TPM in Russia. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to add a second bridge to a nspawn container?
Wojtek Swiatek : > > Hello everyone, > > I have an nspawn container which is currently connected to a bridge on the > host: > > root@srv /e/s/nspawn# cat domotique.nspawn > [Exec] > Boot=yes > [Network] > Bridge=br0 > #Bridge=wlx00c0ca384bd9 > > This results in a host0 interface being present in the container. Everything > works. > > I now would like to add another interface in the container, which would be > bridged with a wireless card on the host. The commented out line above is my > attempt to add another bridge but it failed with > > -- Subject: Unit systemd-nspawn@domotique.service has begun start-up > -- Defined-By: systemd > -- Support: http://www.ubuntu.com/support > -- > -- Unit systemd-nspawn@domotique.service has begun starting up. > Jan 03 17:02:17 srv systemd-nspawn[17264]: Selected user namespace base > 119472128 and range 65536. > Jan 03 17:02:17 srv systemd-nspawn[17264]: Failed to add interface > vb-domotique to bridge wlx00c0ca384bd9: Operation not supported > Jan 03 17:02:17 srv systemd-udevd[17279]: link_config: autonegotiation is > unset or enabled, the speed and duplex are not writable. > Jan 03 17:02:17 srv systemd-timesyncd[791]: Network configuration changed, > trying to establish connection. > Jan 03 17:02:17 srv networkd-dispatcher[906]: WARNING:Unknown index 26 seen, > reloading interface list > Jan 03 17:02:17 srv systemd-timesyncd[791]: Synchronized to time server > 145.238.203.10:123 (ntp.obspm.fr). > Jan 03 17:02:17 srv systemd[1]: systemd-nspawn@domotique.service: Main > process exited, code=exited, status=1/FAILURE > Jan 03 17:02:17 srv systemd[1]: systemd-nspawn@domotique.service: Failed with > result 'exit-code'. > Jan 03 17:02:17 srv systemd[1]: Failed to start Container domotique. > > I am not sure whether "Operation not supported" means that there is something > wrong with that config? or that it is not possible to create a bridge to a > wireless NIC? To be able to participate in a bridge, the wireless card must act as an access point. This restriction comes from the fact that, generally, there are 4 MAC addresses that one needs to be concerned about: Access Point, Station, Source and Destination, but a wireless packet can contain only three distinct ones. Being an access point helps, because one knows that there are no bridges on the far end, i.e. all incoming packets have Station = Source, and all outgoing packets except multicast have Station = Destination. To sidestep this limitation, use something like parprouted instead of a bridge. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Running a service *just* before unmounting filesystems
Hans de Goede : > > Hi All, > > So as you may have heard, I'm working on hiding the grub-menu > by default on single OS Fedora Workstation. Part of the plan > here is to detect if a previous boot was successful and > cleanly shutdown the machine and show the menu (not hide the > menu) if the previous boot has failed to set either the > boot_success or shutdown_success flags: > > https://fedoraproject.org/wiki/Changes/HiddenGrubMenu I think that I have a possibly better idea regarding shutdown. The idea is to modify GRUB so that it can see whether a filesystem has been cleanly unmounted, and use this condition in the "if" blocks. If the root filesystem has not been cleanly unmounted, then the shutdown has likely failed, possibly because the user has pressed a power button for 5 seconds. The problem with this solution is that, upon hibernation, the filesystem will be always dirty (i.e.: false positive), but we can probably manage it with another flag in grubenv. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v230
22.05.2016 13:33, Alexander E. Patrakov пишет: 22.05.2016 03:51, Zbigniew Jędrzejewski-Szmek пишет: Hi, systemd v230 has been tagged. Enjoy! CHANGES WITH 230: * Framebuffer devices (/dev/fb*) and 3D printers and scanners (devices tagged with ID_MAKER_TOOL) are now tagged with "uaccess" and are available to logged in users. Has this been discussed with Wayland developers? Framebuffer device access can possibly be abused to take screenshots and draw on top of the compositor in a Wayland-based environment. Impossibility for arbitrary applications to take screenshots was one of the design goals of Wayland, and this change breaks it. So, unless one of Wayland developers confirms that they are OK with it, please revert it and ask for a CVE. Sorry, I have to take this back. Attempting to grab video from /dev/fb0 here on Intel hardware, both under X and Weston, shows only an image from the first virtual console - i.e. not the actual session. Still, I would like someone else to confirm that this behaviour is not Intel-specific and cannot be circumvented by, say, ioctls on /dev/fb0. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v230
22.05.2016 03:51, Zbigniew Jędrzejewski-Szmek пишет: Hi, systemd v230 has been tagged. Enjoy! CHANGES WITH 230: * Framebuffer devices (/dev/fb*) and 3D printers and scanners (devices tagged with ID_MAKER_TOOL) are now tagged with "uaccess" and are available to logged in users. Has this been discussed with Wayland developers? Framebuffer device access can possibly be abused to take screenshots and draw on top of the compositor in a Wayland-based environment. Impossibility for arbitrary applications to take screenshots was one of the design goals of Wayland, and this change breaks it. So, unless one of Wayland developers confirms that they are OK with it, please revert it and ask for a CVE. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: Setting TasksMax= by default
13.11.2015 20:57, Lennart Poettering wrote: On Fri, 13.11.15 14:27, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: b) I'd like to introduce DefaultTasksMax= that controls the default value of the per-unit TasksMax= by default, and would like it to set to some value such 1024 out-of-the-box. This will mean that any service or scope created will by default be limited to 1024 tasks. This of course is a change from before that has the potential to break some daemons that maintain an excessive number of processes or threads. However, I think it's a much better choice to raise the limit for them, rather than stay unlimited for all services by default. I think 1024 is not particularly low, but also not particularly high. Note that the kernel by default limits the number of processes to 32K in total anyway. Shouldn't it be lower than 1024? For services which have many tasks, 1024 will not be enough, but for 99.9% of services it will be two orders of magnitude too many. I guess we can start with those settings, and the controller turned on, and then maybe readjust based on real-world usage. What are you proposing? 256? 512? (For comparison: if I read the docs right, then Apache defaults to something between 256 and 400 max workers by default, depending on the MPM you pick. If that's a good benchmark, then we should probably not set our own max to anything below 512.) I'd rather not set any default based on Apache. On the contrary, I'd rather force it to be an exception that visibly (for the sysadmin) requires adjusting the limits in the unit file (in other words, has a TasksMax= line with a comment that it has to be changed together with ServerLimit), as it creates one thread or process per connection. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Method to solve a "ordering cycle"
07.09.2015 11:10, Daniel Spannbauer wrote: Sep 04 14:56:04 fry systemd[1]: Trying to enqueue job multi-user.target/start/replace Sep 04 14:56:04 fry systemd[1]: ESC[1;39mFound ordering cycle on remote-fs-pre.target/startESC[0m Sep 04 14:56:04 fry systemd[1]: Walked on cycle path to nss-lookup.target/start Sep 04 14:56:04 fry systemd[1]: Walked on cycle path to named.service/start Sep 04 14:56:04 fry systemd[1]: Walked on cycle path to ldap.service/start Sep 04 14:56:04 fry systemd[1]: Walked on cycle path to remote-fs.target/start Sep 04 14:56:04 fry systemd[1]: Walked on cycle path to owncloud_all.mount/start Sep 04 14:56:04 fry systemd[1]: Walked on cycle path to remote-fs-pre.target/start Sep 04 14:56:04 fry systemd[1]: ESC[1;31mBreaking ordering cycle by deleting job nss-lookup.target/startESC[0m Sep 04 14:56:04 fry systemd[1]: Deleting job postfix.service/start as dependency of job nss-lookup.target/start Which service generates the trouble and what should I do to get rid of this? None of the services in particular generates the trouble. The trouble is from the fact that they all say, collectively, that they need each other. To troubleshoot this, you would need to answer these questions: Do you mount any remote filesystem using the server name, as opposed to its IP address? Do you really need a local instance of named? Does the local named actually get any of its zones from LDAP? Does your LDAP server use any databases stored on a remote filesystem? Do you actually use the owncloud mount? -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Alienware graphics amplifier scancodes
28.05.2015 01:59, Mario Limonciello wrote: Hi, Some Alienware notebooks and desktops support an external graphics housing called the Alienware Graphics Amplifier. It allows the usage of a larger or more modern graphics card than your gaming PC would already support. In order to provide a good experience, systems that support it can provide notification to the OS via the scancodes on the the keyboard controller of events related to the cable. The following 4 events are supported (and the presumed OS response): * Cable plugged in (An app on the existing display or terminal would tell the user to reboot the system to activate) * Undock cable pressed (An app would let the user know to reboot the system to complete undock process; also when supported by GFX driver, driver can clean up and work without a reboot) * Undock hotkey pressed (Same result as undock cable expected) * Surprise removal of cable (System immediately reboots). OK, so you have described GPU hotplug in detail. Please note that Alienware is not the only system that has a hot-pluggable GPU. My laptop, Sony VAIO VPC-Z23A4R, manufactured in 2012, also has a similar facility (the AMD GPU, including two additional outputs, is in the docking station), but AFAIK it is not based on scancodes. So maybe it makes sense to unify handling of the Undock buttons on these devices. Feel free to contact me via email or XMPP (same address) so that we can figure out how to make this possible. P.S. Under Windows 7, if the dock station is configured to be used for additional outputs only, it handles both docking and undocking without a reboot. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] pre-release warnings?
26.05.2015 21:52, Martin Pitt wrote: Lennart Poettering [2015-05-26 18:36 +0200]: That said, I think even better would be to maybe make the support for this generic in systemctl: instead of explicitly invoking chkconfig or update-rcd, maybe we can just make systemctl invoke some fixed binary /usr/lib/systemd/systemd-sysv-compat or so with a fixed set of parameters. The distros could then make that a tool (maybe just a shell script) that invokes chkconfig or update-rc.d This would then allow us to remove any chkconfig-specific code from systemd, and would allow all distros to plug-in the tool of their choice without having to patch upstream. What do you think? That sounds great. If chkconfig and update-r.cd are/were the only two contenders then #ifdef sounds easier, but I don't know about other distros like e. g. Gentoo. With my Gentoo user hat on: Gentoo needs no support here. Their initscripts are based on OpenRC, which is not SysV-compatible enough for the fall back to the initscript logic to make sense at all (e.g., their initscripts have #!/sbin/runscript in the beginning, have no LSB header, and produce an error message if run in the system booted by systemd). In fact, they explicitly disable SysV compatibility in systemd: # disable sysv compatibility --with-sysvinit-path= --with-sysvrcnd-path= -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to wait for specific interface/IP?
26.05.2015 19:03, Lennart Poettering wrote: On Sat, 23.05.15 11:03, Ian Pilcher (arequip...@gmail.com) wrote: Is there a simple way to make a service require that a specific network interface/IP address be active? I have a manually set up bridge and dnsmasq configuration for my VM traffic, but dnsmasq is getting started before NetworkManager has configured the bridge and failing because it cannot bind to the bridge's IP address. Well, for networkd, there's the systemd-networkd-wait-online tool that allows you to wait until a specific interface is up. Maybe NM supports something similar? Please ask NM folks for help. Also, dnsmasq should probably use IP_FREEBIND or so (at least optionally) so that it can work without requiring the interface to be up. dnsmasq supports --bind-dynamic option, which is based not on IP_FREEBIND, but on notifications about new or disappearing interfaces and addresses. The real problem here is with non-C languages. E.g. node.js, Java, Python 2.7 and even Go still have absolutely no support for IP_FREEBIND. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn and IPv6
29.04.2015 11:15, Jörg Thalheim wrote: Well, would that enable automatic, correcting routing between the container and the host's external network? That's kinda what this all is about... Lennart In case we know, which interface provides the external network, it is also possible to use proxy ndp to give containers routeable ips: sysctl -w net.ipv6.conf.if.proxy_ndp=0 ip -6 neigh add proxy ip dev if where if is the external interface and ip is the container ip. Proxy NDP will reply with Neighbor Advertisement on the interface in question if somebody has sended a Neighbor Solicitation messages for an added ip (similar to ARP Requests/Response). To give a container an ip from the subnet advertised on the external interface, it would be required to proxy router advertisements between external interface and bridge (or veth pair). Afaik their is no such proxy for router advertisements, so it would required to bridge the external interface with the bridge (or the host side of the veth pair), which would break the isolation between external and internal network. (Maybe somebody has a better solution on how to get an ip via router advertisement) Such proxy exists, it is a part of odhcpd, which is used in OpenWRT. https://github.com/sbyx/odhcpd -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multipath breaks with recent udev/systemd
15.12.2014 14:31, Hannes Reinecke wrote:
Hi all,
in commit 3ebdb81ef088afd3b4c72b516beb5610f8c93a0d
(udev: serialize/synchronize block device event handling with file
locks) udev started using flock() on the device node, supposedly to
synchronize with an ominous 'block event handling'.
This is a duplicate of the issue that I have reported earlier:
https://www.redhat.com/archives/dm-devel/2014-October/msg00210.html
Therefore, I want to be CCed on replies.
The code looks like this:
if (d) {
fd_lock = open(udev_device_get_devnode(d),
O_RDONLY|O_CLOEXEC|O_NOFOLLOW|O_NONBLOCK);
if (fd_lock = 0 flock(fd_lock,
LOCK_SH|LOCK_NB) 0) {
log_debug(Unable to flock(%s),
skipping event handling: %m, udev_device_get_devnode(d));
err = -EWOULDBLOCK;
goto skip;
}
}
However, multipath since several years is using a similar construct
to lock all devices belonging to a multipath device table before
creating a mulitpath dm-device:
vector_foreach_slot (mpp-pg, pgp, i) {
if (!pgp-paths)
continue;
vector_foreach_slot(pgp-paths, pp, j) {
if (lock flock(pp-fd, LOCK_SH | LOCK_NB)
errno == EWOULDBLOCK)
goto fail;
else if (!lock)
flock(pp-fd, LOCK_UN);
}
}
So during bootup it's anyone's guess who's first, multipath or udev.
And depending on the timing either multipath will fail to setup
the device-mapper device or udev will simply ignore the device.
Neither of those is a good, but the first is an absolute killer for
modern systems which _rely_ on udev to configure devices.
So how it this supposed to work?
Why does udev ignore the entire event if it can't get the lock?
Shouldn't it rather be retried?
What is the supposed recovery here?
Cheers,
Hannes
--
Alexander E. Patrakov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [gummiboot][RFC] Add trusted boot (tboot) support to gummiboot
10.11.2014 14:10, Minchev, Todor wrote: Hello guys, I have been working on adding trusted boot (tboot) support to gummiboot and since this requires quite a bit of new code to be added to the gummiboot code base I wanted to send it out for review and comments. This is the new functionality that these patches add to the gummiboot master branch: - trusted boot support via the tboot module and Intel's Trusted Execution Technology (TXT) - partial multiboot2 support for passing data to the trusted boot module - booting non efi_stub kernels via tboot - no impact on the existing gummiboot functionality I have not looked at the code, but looked at the list of commit messages. In particular: gummiboot: load the loadable segments of the ELF binary and jump to its entry point address As far as I understand, this goes against the design goals of gummiboot of being a simple wrapper that is able to execute EFI binaries and only them. Would it be feasible to convert tboot into an EFI binary instead, and measure/validate it as such, using the API provided by UEFI for that? -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] On /dev/disk/by-id/ata-...-part2 missing, again
Some time ago, I have complained that some boots are unsuccessful, because the /dev/disk/by-id/ata-OCZ-VECTOR_OCZ-Z5CB4KC20X0ZG7F8-part2 symlink (which should point to /dev/sda2) is not created by udev in the initramfs (which uses dracut). Thankfully, people on IRC have suggested some useful debugging options: systemd.log_level=debug rd.udev.log-priority=debug So now I have a SOS report. It is over 1 MB, so not attached. The useful lines are: [3.026515] localhost systemd-udevd[319]: Unable to flock(/dev/sda), skipping event handling: Resource temporarily unavailable [3.027224] localhost systemd-udevd[333]: Unable to flock(/dev/sda), skipping event handling: Resource temporarily unavailable Let me complain here that these error messages still don't contain the complete picture. How am I supposed to know which program in my dracut-created initramfs locks /dev/sda and interferes with udev event handling? -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] On /dev/disk/by-id/ata-...-part2 missing, again
27.10.2014 21:49, Lennart Poettering wrote: On Mon, 27.10.14 21:46, Alexander E. Patrakov (patra...@gmail.com) wrote: Some time ago, I have complained that some boots are unsuccessful, because the /dev/disk/by-id/ata-OCZ-VECTOR_OCZ-Z5CB4KC20X0ZG7F8-part2 symlink (which should point to /dev/sda2) is not created by udev in the initramfs (which uses dracut). Thankfully, people on IRC have suggested some useful debugging options: systemd.log_level=debug rd.udev.log-priority=debug So now I have a SOS report. It is over 1 MB, so not attached. The useful lines are: [3.026515] localhost systemd-udevd[319]: Unable to flock(/dev/sda), skipping event handling: Resource temporarily unavailable [3.027224] localhost systemd-udevd[333]: Unable to flock(/dev/sda), skipping event handling: Resource temporarily unavailable Let me complain here that these error messages still don't contain the complete picture. How am I supposed to know which program in my dracut-created initramfs locks /dev/sda and interferes with udev event handling? Most likely you are either using a too old util-linux, whose use of BSD locks conflict's with udev's use of it. (fsck -l) Please always check README, it will let you know precisely which release of util-linux you need at least. I use fsck from util-linux 2.25.1. Verified by extracting the initramfs. According to the README, this version should be OK, so it must be something else. Here is a list of files in my initramfs which, according to grep, contain the word flock: ./usr/bin/flock ./usr/lib64/systemd/systemd-udevd ./usr/lib64/systemd/systemd-fsck ./usr/lib64/libseccomp.so.2.1.1 ./usr/lib64/libgpg-error.so.0.12.1 ./lib64/modules/3.17.1-gentoo-r1/kernel/fs/afs/kafs.ko ./lib64/modules/3.17.1-gentoo-r1/kernel/fs/cifs/cifs.ko ./lib64/modules/3.17.1-gentoo-r1/kernel/fs/fuse/fuse.ko ./lib64/modules/3.17.1-gentoo-r1/kernel/fs/gfs2/gfs2.ko ./lib64/modules/3.17.1-gentoo-r1/kernel/fs/lockd/lockd.ko ./lib64/modules/3.17.1-gentoo-r1/kernel/fs/nfs/nfs.ko ./lib64/modules/3.17.1-gentoo-r1/kernel/fs/nfs/nfsv4.ko ./lib64/modules/3.17.1-gentoo-r1/kernel/fs/ocfs2/ocfs2.ko ./lib64/modules/3.17.1-gentoo-r1/kernel/fs/xfs/xfs.ko ./lib64/modules/3.17.1-gentoo-r1/modules.symbols ./lib64/dracut-crypt-lib.sh ./lib64/libdevmapper-event.so.1.02 ./lib64/liblvm2cmd.so.2.02 ./lib64/libaudit.so.1.0.0 ./lib64/libc-2.19.so ./lib64/libuuid.so.1.3.0 ./lib64/libmount.so.1.1.0 ./lib64/libpthread-2.19.so ./lib64/libmultipath.so.0 ./sbin/lvm ./sbin/fsck ./sbin/btrfs ./sbin/dhclient ./sbin/btrfsck -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] On /dev/disk/by-id/ata-...-part2 missing, again
27.10.2014 22:13, Lennart Poettering wrote: On Mon, 27.10.14 21:57, Alexander E. Patrakov (patra...@gmail.com) wrote: 27.10.2014 21:49, Lennart Poettering wrote: On Mon, 27.10.14 21:46, Alexander E. Patrakov (patra...@gmail.com) wrote: Some time ago, I have complained that some boots are unsuccessful, because the /dev/disk/by-id/ata-OCZ-VECTOR_OCZ-Z5CB4KC20X0ZG7F8-part2 symlink (which should point to /dev/sda2) is not created by udev in the initramfs (which uses dracut). Thankfully, people on IRC have suggested some useful debugging options: systemd.log_level=debug rd.udev.log-priority=debug So now I have a SOS report. It is over 1 MB, so not attached. The useful lines are: [3.026515] localhost systemd-udevd[319]: Unable to flock(/dev/sda), skipping event handling: Resource temporarily unavailable [3.027224] localhost systemd-udevd[333]: Unable to flock(/dev/sda), skipping event handling: Resource temporarily unavailable Let me complain here that these error messages still don't contain the complete picture. How am I supposed to know which program in my dracut-created initramfs locks /dev/sda and interferes with udev event handling? Most likely you are either using a too old util-linux, whose use of BSD locks conflict's with udev's use of it. (fsck -l) Please always check README, it will let you know precisely which release of util-linux you need at least. I use fsck from util-linux 2.25.1. Verified by extracting the initramfs. According to the README, this version should be OK, so it must be something else. Hmm, please use lslocks or /proc/locks to figure out which process might have the device nodes locked. Thanks for the pointer. It is good to know that the information is available in the kernel. Unfortunately, it is not possible to run the lslocks program manually or see the contents of /proc/locks exactly at the moment when some stupid program decides to lock the device. Especially since this does not happen at every boot. I think that printing the equivalent of the lslocks output directly from udevd when failing to lock the device would be a useful debugging aid. Of course, this feature request only applies when udev.log-priority=debug. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] On /dev/disk/by-id/ata-...-part2 missing, again
27.10.2014 22:28, Lennart Poettering wrote: On Mon, 27.10.14 22:22, Alexander E. Patrakov (patra...@gmail.com) wrote: Thanks for the pointer. It is good to know that the information is available in the kernel. Unfortunately, it is not possible to run the lslocks program manually or see the contents of /proc/locks exactly at the moment when some stupid program decides to lock the device. Especially since this does not happen at every boot. I think that printing the equivalent of the lslocks output directly from udevd when failing to lock the device would be a useful debugging aid. Of course, this feature request only applies when udev.log-priority=debug. Well, to my knowledge there is not efficient way to query this information, so we probably shouldn't do that. That's why I suggested doing it only when debugging is enabled via the kernel command line. Otherwise, all this is left is guessing and code audits - which is worse than the inefficient search for the smoking gun :) If fsck is not the process that takes the locks, I bet LVM is. Are you using that? Consider turning it off. On this machine, LVM is not actually used, but is pulled in as a dependency of udisks-2.1.3. And that dependency is conditional, on the cryptsetup USE flag that is also useless on this desktop. So I think I can indeed remove the lvm binary from this desktop (but not from the Sony laptop). Thanks again! -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] On /dev/disk/by-id/ata-...-part2 missing, again
27.10.2014 22:13, Lennart Poettering wrote: On Mon, 27.10.14 21:57, Alexander E. Patrakov (patra...@gmail.com) wrote: 27.10.2014 21:49, Lennart Poettering wrote: On Mon, 27.10.14 21:46, Alexander E. Patrakov (patra...@gmail.com) wrote: Some time ago, I have complained that some boots are unsuccessful, because the /dev/disk/by-id/ata-OCZ-VECTOR_OCZ-Z5CB4KC20X0ZG7F8-part2 symlink (which should point to /dev/sda2) is not created by udev in the initramfs (which uses dracut). Thankfully, people on IRC have suggested some useful debugging options: systemd.log_level=debug rd.udev.log-priority=debug So now I have a SOS report. It is over 1 MB, so not attached. The useful lines are: [3.026515] localhost systemd-udevd[319]: Unable to flock(/dev/sda), skipping event handling: Resource temporarily unavailable [3.027224] localhost systemd-udevd[333]: Unable to flock(/dev/sda), skipping event handling: Resource temporarily unavailable Let me complain here that these error messages still don't contain the complete picture. How am I supposed to know which program in my dracut-created initramfs locks /dev/sda and interferes with udev event handling? Most likely you are either using a too old util-linux, whose use of BSD locks conflict's with udev's use of it. (fsck -l) Please always check README, it will let you know precisely which release of util-linux you need at least. I use fsck from util-linux 2.25.1. Verified by extracting the initramfs. According to the README, this version should be OK, so it must be something else. Hmm, please use lslocks or /proc/locks to figure out which process might have the device nodes locked. OK, after playing with /etc/ld.so.preload and shared libraries, I found the bad guy. It is multipathd from multipath-tools-0.5.0. I don't use multipath-tools on this desktop, but know why they are here (kpartx was needed at one time in order to debug a partition table issue with a disk image, but now I would probably use a partitioned loop device for the same task). Now they are definitely unneeded. Removed them, but please consider putting a warning in the systemd README file on the incompatibility. As there are no locking-related commits in the multipath-tools repository since 0.5.0, this is definitely not a packaging bug. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM
16.10.2014 01:41, Anatol Pomozov wrote: True. module name should be enough. In this case to debug the issue user needs: - disable failing udev rule (or blacklist module?) - reboot, it will let the user get into shell - modprobe the failing module - use sysrq-trigger to get more information about stuck process Nitpick: this only works only if the stuck modprobe bug is 100% reproducible. Which is not a given. So it is better to collect as much information about the bug when it is noticed by systemd. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [uml-devel] Timed out waiting for device dev-disk-by...
01.10.2014 00:27, Thomas Meyer wrote: Am Montag, den 29.09.2014, 22:20 +0200 schrieb Richard Weinberger: On Mon, Sep 29, 2014 at 8:29 PM, Thomas Meyer tho...@m3y3r.de wrote: Hi, I get a timeout in the Fedora 21 alpha: [ TIME ] Timed out waiting for device dev-disk-by\x2duuid-008af19d\x2d2562\x2d49bd\x2d8907\x2d721ea08f3e14.device. But all devices are available from early kernel start: # ls -l /dev/disk/by-uuid/ total 0 lrwxrwxrwx 1 root root 11 Sep 29 20:17 008af19d-2562-49bd-8907-721ea08f3e14 - ../../ubda1 lrwxrwxrwx 1 root root 11 Sep 29 20:17 e2bffa45-d84f-47bc-81ba-e7a395751fa6 - ../../ubda3 lrwxrwxrwx 1 root root 11 Sep 29 20:17 f452f020-a446-41ed-93c0-ee5ce56d6ea4 - ../../ubda2 It feels like some event notification is lost in the boot process or something like this?! What exactly makes the device unit go into the state active/plugged? This is a boot of the Fedora 21 alpha under user mode linux. Any ideas what could be wrong here? Please always CC me and/or the UML mailinglist in case of UML related issues. I'm very interested in having UML work with systemd. Okay Richard, will do so in future. Some more info about the above systemd wait (with systemd.log_level=debug and DEBUG_KOBJECT) Systemd starts and installs a job for each device tagged with systemd: Sep 30 18:07:58 localhost systemd[1]: Installed new job dev-ubdb3.device/start as 34 Sep 30 18:07:58 localhost systemd[1]: Installed new job systemd-fsck@dev-ubdb3.service/start as 35 Sep 30 18:07:58 localhost systemd[1]: Enqueued job initrd.target/start as 1 Sep 30 18:07:58 localhost systemd[1]: Loaded units and determined initial transaction in 837.189ms. Sep 30 18:07:58 localhost systemd[1]: Received SIGCHLD from PID 32 (n/a). Device unit is waiting: Sep 30 18:07:58 localhost systemd[1]: Expecting device dev-ubdb3.device... udev coldplug: Sep 30 18:08:02 localhost systemd[360]: Executing: /bin/dracut-pre-trigger Sep 30 18:08:02 localhost dracut-pre-trigger[360]: rd.dm=0: removing DM RAID activation Sep 30 18:08:02 localhost systemd-udevd[358]: starting version 215 Sep 30 18:08:02 localhost dracut-pre-trigger[360]: rd.md.imsm=0: no MD RAID for imsm/isw raids Sep 30 18:08:03 localhost dracut-pre-trigger[360]: rd.md.ddf=0: no MD RAID for SNIA ddf raids Sep 30 18:08:03 localhost dracut-pre-trigger[360]: rd.md=0: removing MD RAID activation Sep 30 18:08:04 localhost kernel: kobject: 'alarmtimer' (930ef220): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'alarmtimer' (930ef220): fill_kobj_path: path = '/devices/platform/alarmtimer' Sep 30 18:08:04 localhost kernel: kobject: 'uml-blkdev.1' (605a1700): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'uml-blkdev.1' (605a1700): fill_kobj_path: path = '/devices/platform/uml-blkdev.1' Sep 30 18:08:04 localhost kernel: kobject: 'ubdb' (8c030480): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'ubdb' (8c030480): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb' Sep 30 18:08:04 localhost kernel: kobject: 'ubdb1' (93205838): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'ubdb1' (93205838): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb/ubdb1' Sep 30 18:08:04 localhost kernel: kobject: 'ubdb2' (93205638): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'ubdb2' (93205638): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb/ubdb2' Sep 30 18:08:04 localhost kernel: kobject: 'ubdb3' (93205438): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'ubdb3' (93205438): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb/ubdb3' So here the udev coldplug triggers the kernel kobject_uevent for 'ubdb3'. I don't understand why the systemd unit doesn't change to PLUGGED here! It should?! Or shouldn't it? Imho the problem is not specific to UML. Something similar has been triggered on my desktop PC, and nobody replied: https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg22490.html If this triggers again, I will provide dumps. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] socket-proxyd: Unchecked return value from library
19.09.2014 14:35, Susant Sahani wrote: On 09/19/2014 02:00 PM, David Herrmann wrote: Hi On Fri, Sep 19, 2014 at 10:28 AM, Susant Sahani sus...@redhat.com wrote: On 09/19/2014 01:35 PM, David Herrmann wrote: I don't think that's right. Ignoring the return value of that fcntl is just fine. We read the buffer-size afterwards, so if it failed, we still continue properly. See fcntl(2) for a bunch of errors that might Well I think set and get are two operations. for example let's say set failed but get success. setting BUFFER_SIZE failed and in this case buf size is remained as default pipe size. ..exactly! And the default buffer size is just fine. We'd prefer if we could set it to BUFFER_SIZE, but if we're not allowed to do that, we still continue running with the already set buffer size. yes but how about giving a log for coverity and we ignore the error ? How would an admin react to that log message? I'm fine with it being at the debug priority, but I am not the person who makes decisions here. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM
10.09.2014 12:46, Tom Gundersen пишет: On Tue, Sep 9, 2014 at 10:45 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: On Tue, Sep 9, 2014 at 12:35 PM, James Bottomley james.bottom...@hansenpartnership.com wrote: On Tue, 2014-09-09 at 12:16 -0700, Luis R. Rodriguez wrote: On Mon, Sep 8, 2014 at 10:38 PM, James Bottomley james.bottom...@hansenpartnership.com wrote: If we want to sort out some sync/async mechanism for probing devices, as an agreement between the init systems and the kernel, that's fine, but its a to-be negotiated enhancement. Unfortunately as Tejun notes the train has left which already made assumptions on this. Well, that's why it's a bug. It's a material regression impacting users. Indeed. I believe the issue with this regression however was that the original commit e64fae55 (January 2012) was only accepted by *kernel folks* to be a real regression until recently. Just for the record, this only caused user-visible problems after kernel commit 786235ee (November 2013), right? No. The pata-marvell (or rather libata in general) problem existed before that. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM
10.09.2014 12:58, Tom Gundersen пишет: On Wed, Sep 10, 2014 at 8:53 AM, Alexander E. Patrakov patra...@gmail.com wrote: 10.09.2014 12:46, Tom Gundersen пишет: On Tue, Sep 9, 2014 at 10:45 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: On Tue, Sep 9, 2014 at 12:35 PM, James Bottomley james.bottom...@hansenpartnership.com wrote: On Tue, 2014-09-09 at 12:16 -0700, Luis R. Rodriguez wrote: On Mon, Sep 8, 2014 at 10:38 PM, James Bottomley james.bottom...@hansenpartnership.com wrote: If we want to sort out some sync/async mechanism for probing devices, as an agreement between the init systems and the kernel, that's fine, but its a to-be negotiated enhancement. Unfortunately as Tejun notes the train has left which already made assumptions on this. Well, that's why it's a bug. It's a material regression impacting users. Indeed. I believe the issue with this regression however was that the original commit e64fae55 (January 2012) was only accepted by *kernel folks* to be a real regression until recently. Just for the record, this only caused user-visible problems after kernel commit 786235ee (November 2013), right? No. The pata-marvell (or rather libata in general) problem existed before that. Thanks. I have missed that. Link? https://bugzilla.kernel.org/show_bug.cgi?id=59581 -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM
probes are simply fine. My patch to pick up misbehaving drivers drivers on the kernel front by picking up systemd's signal was reactive but it was also simply braindead given the same exact reasons why systemd's original timeout was flawed. We want a general solution and we don't want to work around the root cause, in this case it was systemd's assumption on how drivers work. Keep in mind that the above just addresses kmod built-in cmd on systemd, its where the timeout was introduced but as has been clarified here assuming the same timeout on *all* other built-in likely is likely pretty flawed as well and this does concern me. Its why I mentioned that more than two years have gone by now on growing design and assumptions on top of that original commit and its why its hard for systemd to consider an alternative. I'm afraid distributions that want to avoid this sigkill at least on the kernel front will have to work around this issue either on systemd by increasing the default timeout which is now possible thanks to Hannes' changes or by some other means such as the combination of a modified non-chatty version of this patch + a check at the end of load_module() as mentioned earlier on these threads. Increasing the default timeout in systemd seems like the obvious bug fix to me. If the patch exists already, having distros that want it use it looks to be correct ... not every bug is a kernel bug, after all. Its merged upstream on systemd now, along with a few fixes on top of it. I also see Kay merged a change to the default timeout to 60 second on August 30. Its unclear if these discussions had any impact on that decision or if that was just because udev firmware loading got now ripped out. I'll note that the new 60 second timeout wouldn't suffice for cxgb4 even if it didn't do firmware loading, its probe takes over one full minute. Negotiating a probe vs init split for drivers is fine too, but it's a longer term thing rather than a bug fix. Indeed. What I proposed with a multiplier for the timeout for the different types of built in commands was deemed complex but saw no alternatives proposed despite my interest to work on one and clarifications noted that this was a design regression. Not quite sure what else I could have done here. I'm interested in learning what the better approach is for the future as if we want to marry init + kernel we need a smooth way for us to discuss design without getting worked up about it, or taking it personal. I really want this to work as I personally like systemd so far. How about this: keep the timeout global, but also introduce a (relatively short, say 10 or 15 seconds) timeout after which a warning is printed. That is something that I originally was looking forward to on systemd, but here's the thing once that warning comes up -- what would we do with it? This patch addresses this warning in-kernel and the idea was that we'd then peg an async_probe bool as true on the driver as a fix, that was decided to be silly given all the above. These drivers are actually not misbehaving and it would be even more incorrect to try to fix them by making them run asynchronously. In fact for some old storage drivers it may even be the worst thing to do given the possible slew of userland deployment and scripts which assume things *are* synchronous. Even if nothing is actually killed, having workers (be it insmod or something else) take longer than a couple of seconds is likely a sign that something is seriously off somewhere. Probe can take a long time and that's fine, so for kmod the current assumption is flawed. If we had an option to async probe all drivers then perhaps this kmod timeout *might be reasonable*, and even then I do recommend for a clear warning that can be collected on logs on its first iteration rather than sigkilling, only after a whlie should sigkilling be done really. If systemd can deal with module loading in the background for drivers that take a long time and warning on that intsead of sigkiling it may be good start prior to enabling a default sigkill on drivers. This is perhaps also true for other workers but its not clear if this is a reasonable strategy for systemd. Luis Just two small remarks to the whole thread. First, I am quite surprised that nobody brought up the argument that module loading is serialized by the kernel. So, while pata-marvell on my laptop does its dirty wait-reset-wait-reset-work thing, no other module can be loaded. This prevention of loading other drivers is the thing that slows down the boot. Second, I am going to XDC2014, LinuxCon Europe and Plumbers. I will take my laptop with me, feel free to see the situation firsthand or try debugging patches. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] You are invited to give your thoughts on some async-signal-safety issues.
31.08.2014 09:31, Steven Stewart-Gallus wrote: Hello, I understand that systemd uses sandboxing and multithreading. After a fork, many things are messed up so it's only practical to use async-signal-safe functions after a fork from a threaded program. If you have ideas on what sort of functionality GLibc needs to change to make systemd more async-signal-safe after a fork you are invited to give your thoughts on the GLibc mailing list in the thread at https://sourceware.org/ml/libc-help/2014-08/msg00039.html. Sorry for a late reply, but I think you should ask Redis folks about async-signal safety issues. They use fork quite non-trivially for background saving of their database from memory to disk. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-215: could not boot, missing /dev/disk/...-part2 symlink
Hello.
I have a Gentoo system, with btrfs on /dev/sda2 (also known as
/dev/disk/by-id/ata-OCZ-VECTOR_OCZ-Z5CB4KC20X0ZG7F8-part2) and with
dracut 038 with Gentoo patches that you can view here:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-kernel/dracut/files/
(see 0038-*)
Today, I powered the computer on (without applying any updates since the
previous successful boot), but the boot stalled, and I was dropped into
an emergency shell. I have saved the SOS report, see the attachment.
As you can see, /dev/sda2 exists, but the link doesn't. udevadm
trigger helped it to appear, and the boot continued.
I initially thought that it might be due to locking that systemd-udevd
applies to block devices for the period of running its IMPORT{program}
rules. Look: if in worker_new() the lock is not acquired successfully,
then the event processing is skipped (and this also means symlinks are
not created). But then there should be an Unable to flock debug
message in journalctl -b -p debug, and it doesn't exist. So it must be
something else. Any other ideas?
--
Alexander E. Patrakov
+ cat /lib/dracut/dracut-038-r2
dracut-038-r2
+ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz
root=/dev/disk/by-id/ata-OCZ-VECTOR_OCZ-Z5CB4KC20X0ZG7F8-part2
usbcore.autosuspend=0 log_buf_len=524288 intel_iommu=igfx_off rootfstype=btrfs
rootflags=subvol=kde,compress rw init=/usr/lib/systemd/systemd rd.info
initrd=/initramfs.img
+ '[' -f /etc/cmdline ']'
+ for _i in '/etc/cmdline.d/*.conf'
+ '[' -f /etc/cmdline.d/base.conf ']'
+ echo /etc/cmdline.d/base.conf
/etc/cmdline.d/base.conf
+ cat /etc/cmdline.d/base.conf
ro
+ cat /proc/self/mountinfo
0 0 0:1 / / rw shared:1 - rootfs rootfs rw
14 0 0:14 / /sys rw,nosuid,nodev,noexec,relatime shared:2 - sysfs sysfs rw
15 0 0:3 / /proc rw,nosuid,nodev,noexec,relatime shared:7 - proc proc rw
16 0 0:5 / /dev rw,nosuid shared:8 - devtmpfs devtmpfs
rw,size=8135608k,nr_inodes=2033902,mode=755
17 14 0:15 / /sys/kernel/security rw,nosuid,nodev,noexec,relatime shared:3 -
securityfs securityfs rw
18 16 0:16 / /dev/shm rw,nosuid,nodev shared:9 - tmpfs tmpfs rw
19 16 0:11 / /dev/pts rw,nosuid,noexec,relatime shared:10 - devpts devpts
rw,gid=5,mode=620,ptmxmode=000
20 0 0:17 / /run rw,nosuid,nodev shared:11 - tmpfs tmpfs rw,mode=755
21 14 0:18 / /sys/fs/cgroup ro,nosuid,nodev,noexec shared:4 - tmpfs tmpfs
ro,mode=755
22 21 0:19 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime shared:5 -
cgroup cgroup
rw,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd
23 14 0:20 / /sys/fs/pstore rw,nosuid,nodev,noexec,relatime shared:6 - pstore
pstore rw
24 21 0:21 / /sys/fs/cgroup/cpuset rw,nosuid,nodev,noexec,relatime shared:12 -
cgroup cgroup rw,cpuset
25 21 0:22 / /sys/fs/cgroup/cpu,cpuacct rw,nosuid,nodev,noexec,relatime
shared:13 - cgroup cgroup rw,cpu,cpuacct
26 21 0:23 / /sys/fs/cgroup/memory rw,nosuid,nodev,noexec,relatime shared:14 -
cgroup cgroup rw,memory
27 21 0:24 / /sys/fs/cgroup/devices rw,nosuid,nodev,noexec,relatime shared:15 -
cgroup cgroup rw,devices
28 21 0:25 / /sys/fs/cgroup/freezer rw,nosuid,nodev,noexec,relatime shared:16 -
cgroup cgroup rw,freezer
29 21 0:26 / /sys/fs/cgroup/net_cls rw,nosuid,nodev,noexec,relatime shared:17 -
cgroup cgroup rw,net_cls
30 21 0:27 / /sys/fs/cgroup/blkio rw,nosuid,nodev,noexec,relatime shared:18 -
cgroup cgroup rw,blkio
31 21 0:28 / /sys/fs/cgroup/hugetlb rw,nosuid,nodev,noexec,relatime shared:19 -
cgroup cgroup rw,hugetlb
51 14 0:29 / /sys/kernel/config rw,relatime shared:20 - configfs configfs rw
+ cat /proc/mounts
rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
devtmpfs /dev devtmpfs rw,nosuid,size=8135608k,nr_inodes=2033902,mode=755 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup
rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd
0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup
rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/net_cls cgroup rw,nosuid,nodev,noexec,relatime,net_cls 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/hugetlb cgroup rw,nosuid,nodev,noexec,relatime,hugetlb 0 0
configfs /sys/kernel/config
Re: [systemd-devel] systemd-213: regression with zram
24.06.2014 12:22, Minchan Kim wrote: Hello, Sorry for the late response. Better late than never. If I parse your problem correctly, you meant that changing disksize is failed while someone opens /dev/zram0? I tried test which opens /dev/zram0 with O_RDWR and sleep forever and then echo $((51220)) /sys/block/zram0/disksize is successful. IOW, it's okay with me. No, this is only a part of the problem. A valid test would be: 0. Reset the unused zram device. 1. Use a program that opens /dev/zram0 with O_RDWR and sleeps until killed. 2. While that program sleeps, echo the correct value to /sys/block/zram0/disksize. 3. Verify (e.g. in /proc/partitions) that the disk size is applied correctly. It is. 4. While that program still sleeps, attempt to mkswap /dev/zram0. This fails: mkswap: error: swap area needs to be at least 40 KiB There is nothing in dmesg. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-213: regression with zram
25.06.2014 06:36, Minchan Kim wrote:
Could you test this patch? It passed my test.
Thanks!
From 4ab4931c3fa7e6527e3a849d5e4c4f727143e66c Mon Sep 17 00:00:00 2001
From: Minchan Kim minc...@kernel.org
Date: Wed, 25 Jun 2014 09:20:24 +0900
Subject: [PATCH] zram: revalidate disk after capacity change
Alexander reported mkswap on /dev/zram0 is failed if other process
is opening the block device file.
Step is as follows,
0. Reset the unused zram device.
1. Use a program that opens /dev/zram0 with O_RDWR and sleeps until killed.
2. While that program sleeps, echo the correct value to
/sys/block/zram0/disksize.
3. Verify (e.g. in /proc/partitions) that the disk size is applied correctly.
It is.
4. While that program still sleeps, attempt to mkswap /dev/zram0. This fails:
result: mkswap: error: swap area needs to be at least 40 KiB
When I investigated, the size get by ioctl(fd, BLKGETSIZE64) on mkswap
to get a size of blockdev was zero although zram0 has right size
by 2.
The reason is zram didn't revalidate disk after changing capacity
so that size of blockdev's inode is not uptodate until all of file is close.
This patch should fix the problem.
Reported-by: Alexander E. Patrakov patra...@gmail.com
Signed-off-by: Minchan Kim minc...@kernel.org
Tested-by: Alexander E. Patrakov patra...@gmail.com
It indeed fixes the problem.
---
drivers/block/zram/zram_drv.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 48eccb350180..089e72cd37be 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -622,8 +622,10 @@ static void zram_reset_device(struct zram *zram, bool
reset_capacity)
memset(zram-stats, 0, sizeof(zram-stats));
zram-disksize = 0;
- if (reset_capacity)
+ if (reset_capacity) {
set_capacity(zram-disk, 0);
+ revalidate_disk(zram-disk);
+ }
up_write(zram-init_lock);
}
@@ -664,6 +666,7 @@ static ssize_t disksize_store(struct device *dev,
zram-comp = comp;
zram-disksize = disksize;
set_capacity(zram-disk, zram-disksize SECTOR_SHIFT);
+ revalidate_disk(zram-disk);
up_write(zram-init_lock);
return len;
--
Alexander E. Patrakov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 214
11.06.2014 23:00, Lennart Poettering wrote: CHANGES WITH 214: * As an experimental feature, udev now tries to lock the disk device node (flock(LOCK_SH|LOCK_NB)) while it executes events for the disk or any of its partitions. Applications like partitioning programs can lock the disk device node (flock(LOCK_EX)) and claim temporary device ownership that way; udev will entirely skip all event handling for this disk and its partitions. If the disk was opened for writing, the close will trigger a partition table rescan in udev's watch facility, and if needed synthesize change events for the disk and all its partitions. This is now unconditionally enabled, if it turns out to cause major problems, we might turn it on only for specific devices, or might need to disable it entirely. Device-mapper devices are excluded from this logic. If we have one exception, I think it is safe to ask another: all block devices starting with zram. The reason is documented at http://lists.freedesktop.org/archives/systemd-devel/2014-June/019838.html : it breaks a (mis-?)documented way to integrate zram swap and systemd. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-213: regression with zram
09.06.2014 19:26, Kai Krakow wrote: Alexander E. Patrakov patra...@gmail.com schrieb: I have upgraded systemd from 212 to 213 on two my Gentoo boxes, and see the same regression here: zram swap space does not get activated. It looks like systemd tries to activate swap before the RUN+=mkswap part of the udev rule finishes. Here are the relevant lines from my configuration files. Are they indeed supposed to work, or were working only by pure luck? I switched to zswap because of this. This also looks more appropriate for my workload. Maybe that's an option? At least if you do have a physical swap device (and in that cased I'd prefer zswap over zram). Please don't persuade me to hide or tolerate bugs. Even if zswap is more appropriate, I would like to get a comment on my zram issue from systemd maintainers. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-213: regression with zram
09.06.2014 20:11, Kay Sievers wrote:
On Mon, Jun 9, 2014 at 4:02 PM, Alexander E. Patrakov
patra...@gmail.com wrote:
09.06.2014 19:26, Kai Krakow wrote:
Alexander E. Patrakov patra...@gmail.com schrieb:
I have upgraded systemd from 212 to 213 on two my Gentoo boxes, and see
the same regression here: zram swap space does not get activated. It
looks like systemd tries to activate swap before the RUN+=mkswap part of
the udev rule finishes.
Here are the relevant lines from my configuration files. Are they indeed
supposed to work, or were working only by pure luck?
I switched to zswap because of this. This also looks more appropriate for
my
workload. Maybe that's an option? At least if you do have a physical swap
device (and in that cased I'd prefer zswap over zram).
Please don't persuade me to hide or tolerate bugs. Even if zswap is more
appropriate, I would like to get a comment on my zram issue from systemd
maintainers.
I don't know of anybody working on systemd, using this
horrible-to-configure facility.
I have no idea how stuff should work, but it *might* need some
ENV{SYSTEMD_READY}=0 fiddling.
Let's decompose the question then. Maybe you know how at least one of
the steps should work.
1. Is it correct that swap units created from /etc/fstab have
dependencies on the devices mentioned in the first column? What kind of
dependencies?
2. At what point in time (just after getting the uevent, after setting
sysfs attributes, after running the RUN programs) is the dependency on
the device node considered satisfied?
Module parameters to configure devices, sysfs attributes to
re-configure pre-created dead devices, ...; given the fact, that it
is relatively recent technology, such terribly outdated and
have-always-been-broken concepts should never have been merged into
the kernel.
A valid observation, but still - the semantics need to be documented
(even if the document says undefined) in systemd.device(5) or
elsewhere WRT dependencies and ordering.
--
Alexander E. Patrakov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] no fsck at boot
10.06.2014 00:04, Reindl Harald wrote: Am 09.06.2014 17:05, schrieb Colin Guthrie: 'Twas brillig, and Reindl Harald at 08/06/14 13:59 did gyre and gimble: touch /forcefsck leads in deprecated warnings but in fact at least on Fedora 19 *you need it* because the fsck don't happen otherwise for sure, the last reboot of the machine below complaind too so why don't it happen at boot? Via what mechanism did you trigger the fsck at boot (other than /forcefsck)? e.g. did you pass fsck.mode=force on the kernel command line (as the deprecated warning suggests)? Did this not trigger things correctly? uhm you stripped the relevant part of my message * the filesystem has reached the time for next fsck * the kernel says it's time * before systemd did happended automatically * that is why ext4 defines the fsck interval at all Please paste your /etc/fstab file. If it has 0 0 as the last two fields, then, of course, systemd will not call fsck. If there are different numbers there, sure, let's debug. Also, now the entity that is supposed to check your root filesystem is dracut. Are you using it? Does the problem go away if you regenerate your initramfs? -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] no fsck at boot
10.06.2014 00:57, Reindl Harald wrote: Am 09.06.2014 20:45, schrieb Alexander E. Patrakov: 10.06.2014 00:04, Reindl Harald wrote: Am 09.06.2014 17:05, schrieb Colin Guthrie: 'Twas brillig, and Reindl Harald at 08/06/14 13:59 did gyre and gimble: touch /forcefsck leads in deprecated warnings but in fact at least on Fedora 19 *you need it* because the fsck don't happen otherwise for sure, the last reboot of the machine below complaind too so why don't it happen at boot? Via what mechanism did you trigger the fsck at boot (other than /forcefsck)? e.g. did you pass fsck.mode=force on the kernel command line (as the deprecated warning suggests)? Did this not trigger things correctly? uhm you stripped the relevant part of my message * the filesystem has reached the time for next fsck * the kernel says it's time * before systemd did happended automatically * that is why ext4 defines the fsck interval at all Please paste your /etc/fstab file. If it has 0 0 as the last two fields, then, of course, systemd will not call fsck. If there are different numbers there, sure, let's debug. Also, now the entity that is supposed to check your root filesystem is dracut. Are you using it? Does the problem go away if you regenerate your initramfs? i know how to deal with fstab and column 6 is not zero as well as the initramfs is regenrated all the time because kernel updates which are *the reason* for reboots on servers at all what disturbs me is they warning about touch /forcefsck while it's currently the *only* option to trigger a recommended fsck at boot on a remote-server (and no add kernel params for that in the grub-config and remove them after is not a sane way for sysadmins maintaining 10,20,30 remote servers) UUID=209aeed4-95bd-4eb0-bdfa-fb346b603ce9 /boot ext4 defaults 0 1 UUID=22f62744-8fd7-4090-aff8-b35ef38b4b74 / ext4 defaults,commit=5,inode_readahead_blks=128,noatime,nodiratime,noquota 0 1 UUID=0b95905b-02c5-444b-af9e-7615cabebb38 /mnt/data ext4 defaults,commit=5,inode_readahead_blks=128,noatime,nodiratime,noquota,nosuid 0 2 OK. Let's try eliminating some more reasons why fsck can be skipped. 1. The root filesystem is mounted read-write at boot [but note that this doesn't explain failures to check other filesystems] 2. The generator did not run for some unknown reason. 3. Some other error that got hopefully logged. Could you please attach the output of: ls -lR /run/systemd/generator journalctl -b Also, could you please try replacing some non-critical UUID=... lines (e.g. for /boot) in your fstab by direct device references of the form /dev/disk/by-uuid/209aeed4-95bd-4eb0-bdfa-fb346b603ce9 or even /dev/mdX, just to see if that's UUID who triggers the bug for you? To avoid getting an inaccessible server if that misfires, you can also append nofail to the options for /boot. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-213: regression with zram
Hello.
I have upgraded systemd from 212 to 213 on two my Gentoo boxes, and see
the same regression here: zram swap space does not get activated. It
looks like systemd tries to activate swap before the RUN+=mkswap part of
the udev rule finishes.
Here are the relevant lines from my configuration files. Are they indeed
supposed to work, or were working only by pure luck?
$ cat /etc/modules-load.d/zram.conf
zram
$ cat /etc/modprobe.d/zram.conf
options zram num_devices=4
$ cat /etc/udev/rules.d/01-zram.rules
KERNEL==zram[0-9], SUBSYSTEM==block, DRIVER==, ACTION==add,
ATTR{disksize}==0, ATTR{disksize}=1536M, RUN+=/sbin/mkswap
$env{DEVNAME}
$ grep zram /etc/fstab
/dev/zram0 noneswappri=10,discard 0 0
/dev/zram1 noneswappri=10,discard 0 0
/dev/zram2 noneswappri=10,discard 0 0
/dev/zram3 noneswappri=10,discard 0 0
--
Alexander E. Patrakov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] GuessMainPID=no required to make daemon reload work
05.05.2014 21:14, Lennart Poettering wrote: On Mon, 05.05.14 10:00, Gerd v. Egidy (li...@egidy.de) wrote: systemd will behave as expected: once your main process terminates it will re-read PID from this file (assuming that before dying your old process writes its child's PID) and set it as MAINPID for your service. Hmm. Currently it is done like this: the old daemon releases the lock on the pidfile and terminates itself. The new daemon detects this and then writes it's own pid to the pidfile and locks it. So there is a short time where the old daemon is already dead and the new one hasn't written it's pid yet. Probably this is the problem. But I have to think about a way to get the locking stuff right as I can't easily transfer the lock over an exec. Generally, it's not a good idea to keep file locks for a longer period of time... YOu should really just take them while you write a file, and then release them, but not keep them forever... Note that man 7 daemon, which is a part of systemd, contains this paragraph: 12. In the daemon process, write the daemon PID (as returned by getpid()) to a PID file, for example /run/foobar.pid (for a hypothetical daemon foobar) to ensure that the daemon cannot be started more than once. This must be implemented in race-free fashion so that the PID file is only updated when it is verified at the same time that the PID previously stored in the PID file no longer exists or belongs to a foreign process. Commonly, some kind of file locking is employed to implement this logic. I guess that the text needs to be clarified, as currently it is a source of long-living locks on PID-files, with the associated vulnerabilities. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Dead link in man 7 daemon
Hello. man 7 daemon links to Apple MacOS X Daemon Requirements: http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPSystemStartup/Articles/LaunchOnDemandDaemons.html#//apple_ref/doc/uid/TP40001762-104738 However, the link is dead. The correct link is: https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] On the recent commit conf-parser: never consider it an error
Hello. The code touched by commit 9f43a07f1 is possibly buggy. Here is why I think so. The new lines added are: log_full(errno == ENOENT ? LOG_DEBUG : LOG_ERR, Failed to open configuration file '%s': %m, filename); return errno == ENOENT ? 0 : -errno; However, I don't understand why errno in the second line is the original errno. I.e. why log_full() can't clobber the errno with some other error that happens while logging. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
2014-03-08 1:37 GMT+06:00 Lennart Poettering lenn...@poettering.net: And for the root disk we declare explicitly that installers may only drop the root= param from the kernel cmdline if the OS is installed as first root partition on the disk. Otherwise it *must* specify it to make sure the right partition is found at boot. I see a potential problem here. Even if this partition is the first root partition now, there is no guarantee that it will remain to be the first root partition after one frees an existing data partition (that happened to go before root) and installs the next linux distro on it. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Regarding how to properly use zram on a systemd setup
02.02.2014 17:23, Pacho Ramos wrote:
Hello
After reading:
http://www.chromestory.com/2013/03/google-enabling-zram-for-chrome-os-by-default/
http://lwn.net/Articles/545244/
I was wondering what would be the best way to use zram on a setup
running systemd. This is because I have found a lot of scripts, unit
files... but I don't know what is the best approach (at least from an
upstream point of view):
http://mystilleef.blogspot.com.es/2011/10/enable-zram-in-fedora.html
http://software.opensuse.org/package/systemd-zram-service
https://aur.archlinux.org/packages/zramswap/
I found this thread:
http://lists.freedesktop.org/archives/systemd-devel/2012-November/007444.html
In that one Lennart suggest that maybe some action from util-linux
maintainers could help but, after that message, I don't see anything
newer (maybe we could report that suggestion to util-linux maintainers
to other place... or maybe a better solution was found later :/)
Thanks a lot for your help and suggestions
Here is what I use. I don't claim this to be the best or even
officially-approved solution. But this is based on the existing Gentoo
documentation, found at
http://wiki.gentoo.org/wiki/Zram#Using_existing_tools :)
$ cat /etc/udev/rules.d/10-zram.rules
KERNEL==zram[0-9], SUBSYSTEM==block, DRIVER==, ACTION==add,
ATTR{disksize}==0, ATTR{disksize}=1536M, RUN+=/sbin/mkswap
$env{DEVNAME}
$ cat /etc/fstab
# /etc/fstab: static file system information.
snip irrelenavt lines
/dev/zram0 noneswappri=10,discard 0 0
/dev/zram1 noneswappri=10,discard 0 0
/dev/zram2 noneswappri=10,discard 0 0
/dev/zram3 noneswappri=10,discard 0 0
Note that discard is essential here (and not mentioned in the Gentoo
wiki) so that zram returns once-used compressed swap to the system.
$ cat /etc/modprobe.d/zram.conf
options zram num_devices=4
$ cat /etc/modules-load.d/zram.conf
zram
--
Alexander E. Patrakov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Adding zram to inappropriate block device
02.02.2014 19:29, Jóhann B. Guðmundsson wrote:
---
rules/60-persistent-storage.rules | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rules/60-persistent-storage.rules
b/rules/60-persistent-storage.rules
index a4d009a..154ffd9 100644
--- a/rules/60-persistent-storage.rules
+++ b/rules/60-persistent-storage.rules
@@ -14,7 +14,7 @@ ACTION==add, SUBSYSTEM==module, KERNEL==block,
ATTR{parameters/events_dfl_
SUBSYSTEM!=block, GOTO=persistent_storage_end
# skip rules for inappropriate block devices
-KERNEL==fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md*, GOTO=persistent_storage_end
+KERNEL==fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md*|zram*,
GOTO=persistent_storage_end
# ignore partitions that span the entire disk
TEST==whole_disk, GOTO=persistent_storage_end
The patch is obviously harmless. However, I am not convinced that it is
needed, because in my setup (without this patch) there are no links in
/dev/disk pointing to any zram device. You can change my opinion by
providing configuration files that do result in such links being created
by systemd.
See
http://lists.freedesktop.org/archives/systemd-devel/2014-February/016614.html
for my configuration files.
offtopic
One patch that would be useful, however, is to make systemd say this
system cannot hibernate if all swap devices are zrams.
/offtopic
--
Alexander E. Patrakov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Adding zram to inappropriate block device
02.02.2014 20:18, Jóhann B. Guðmundsson wrote: On 02/02/2014 01:39 PM, Alexander E. Patrakov wrote: The patch is obviously harmless. However, I am not convinced that it is needed, because in my setup (without this patch) there are no links in /dev/disk pointing to any zram device. You can change my opinion by providing configuration files that do result in such links being created by systemd. udev seems to have a race condition with swapon to see which can open /dev/zram0 first, causing swapon to fail. ( seems to be most noticeable on arm devices one out of every 7 times or something ) and this patches udev's persistent storage rules to avoid probing any zram devices. Thanks, this explains why the patch is needed. But this should really be in the commit message :) -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-bugs] Russian translation for systemd
2013/11/17 Sergey Ptashnick 0comff...@inbox.ru: On 16.11.2013 20:40, Zbigniew Jędrzejewski-Szmek wrote: Can one of you prepare a merge of both translations, picking the best parts? Done. I also updated russian catalog for Journal (in according to commit 9444b1f2). Julia, Alexander, any comments? The translation is at least self-consistent now, good! However, I am not quite sure that it is consistent with the existing translations from GNOME or KDE power management applications. I will check and report that separately. I do have some comments, though. #: ../src/login/org.freedesktop.login1.policy.in.h:19 msgid Allow non-logged-in users to run programs msgstr Разрешить пользователям оставлять программы в фоновом режиме после завершения сеанса That's a rather creative rewording. In fact, it may be more to the point than the original English string, but I am not 100% sure. Code authors, could you please comment whether this back-translation from Russian into English makes sense in the original context? Allow users to leave programs running in the background after logging out #: ../src/login/org.freedesktop.login1.policy.in.h:21 msgid Allow attaching devices to seats msgstr Разрешить подключение устройств к терминалу Is there any prior art for translating seat as терминал? Won't that clash with tty at some point? -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-bugs] Russian translation for systemd
Sergey Ptashnick wrote: On 16.11.2013 20:40, Zbigniew Jędrzejewski-Szmek wrote: Can one of you prepare a merge of both translations, picking the best parts? Done. I also updated russian catalog for Journal (in according to commit 9444b1f2). Julia, Alexander, any comments? As promised, here are comments regarding cross-project consistency. Not sure, though, if such consistency is a worthy goal, and these differences might as well be bugs in GDM and KDM translation. For reference, here are *.po files from these projects: https://git.gnome.org/browse/gdm/tree/po/ru.po http://websvn.kde.org/trunk/l10n-kde4/ru/messages/kde-workspace/kdmconfig.po?view=markup http://websvn.kde.org/trunk/l10n-kde4/ru/messages/kde-workspace/kdmgreet.po?view=markup You translate host name as имя компьютера, both GDM and KDM translators use имя узла. You translate seat as терминал (which I already objected to), GDM translators use рабочее место, KDM is not seat-aware. You translate authentication is required as необходимо пройти идентификацию, GDM translators use the word аутентификация, KDM translators are inconsistent (use both terms). As for session (found in the catalog file), you both use the term сеанс, which is good. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-bugs] Russian translation for systemd
2013/11/18 Sergey Ptashnick 0comff...@inbox.ru: On 17.11.2013 16:34, Alexander E. Patrakov wrote: You translate host name as имя компьютера, both GDM and KDM translators use имя узла. In this case, IMHO, evidence and intuitivity have priority over consistency. Please tell if you think I'm wrong. You translate seat as терминал (which I already objected to), GDM translators use рабочее место, KDM is not seat-aware. Fixed. You translate authentication is required as необходимо пройти идентификацию, GDM translators use the word аутентификация, KDM translators are inconsistent (use both terms). I have changed аутентификация-идентификация mainly for Julia. Reverted now. I don't have any objections now. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-bugs] Russian translation for systemd
2013/11/15 Sergey Ptashnick 0comff...@inbox.ru: Пятница, 15 ноября 2013, 17:07 +04:00 от Juliette Tux juliette@gmail.com: Fixed version, see attachment. And I'm done with it. Too much fuss about these 70 messages. Please just accept it, the translation is good. I'm sorry, but I can't agree with the last statement. This translation still requires some polishing. Several examples: 1. Настроить системные настройки клавиатуры Ugly tautology (настроить настройки) can be easily avoided without distortion of meaning: Настройка параметров клавиатуры Right. 2. при наличии приложения, делающего запрос на блокировку This phrase is also ugly and confusing. Maybe, при наличии приложения, запросившего блокировку? Yes, this is shorter and has the same meaning. 3. Чтобы перезагрузить систему при наличии других авторизованных в ней пользователей Continuing the previous discussions, authorized is not equal to logged in. If user *can* log in into the system, he's authorized. If user actually logged in, he is... logged in. Maybe, несмотря на то, что в системе работают другие пользователи? Yes. Perhaps it would be optimal if you take my version as a basis and remove аутентификацию from there as you like? P.S. Maybe I'm captious. Let's ask the other native speakers. Alexander, Andrey? As a would-be manager, I would ask just one thing: who is ready to maintain the translation if new translatable strings are added to systemd? The And I'm done with it indicates that the original submitter is likely not ready for that. As for the translation itself, from my own viewpoint, it is not good enough to be a final version, but good enough to be commited in a disabled state so that others can improve it. It is not a problem that we can't make a perfect translation in just one commit. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-bugs] Russian translation for systemd
2013/11/14 Juliette Tux juliette@gmail.com: Proposed patch for adding Russian translation to systemd, see attachment I have some remarks regarding translation consistency. +#: ../src/hostname/org.freedesktop.hostname1.policy.in.h:1 +msgid Set host name +msgstr Указать имя узла + +#: ../src/hostname/org.freedesktop.hostname1.policy.in.h:2 +msgid Authentication is required to set the local host name. +msgstr Для настройки имени локального узла требуется авторизация. + +#: ../src/hostname/org.freedesktop.hostname1.policy.in.h:3 +msgid Set static host name +msgstr Указать статическое имя узла You use two different Russian verbs (указать, настроить) for the same English term to set when it is applied to host names. +#: ../src/hostname/org.freedesktop.hostname1.policy.in.h:4 +msgid +Authentication is required to set the statically configured local host name, +as well as the pretty host name. +msgstr +Для настройки статического имени локального узла, а также чудесного +имени вашей машины, требуется авторизация. I have never seen pretty translated as чудесный in such context (where the meaning is descriptive, meaningful). Could you please show some prior art? +#: ../src/login/org.freedesktop.login1.policy.in.h:5 +msgid Allow applications to inhibit system sleep +msgstr Разрешить приложениям блокировать спящий режим системы. In all other places you use the word активация to designate the transition into some other low-power state. Maybe it is a good idea to use it here, too. +#: ../src/login/org.freedesktop.login1.policy.in.h:17 +msgid Allow applications to inhibit system handling of the lid switch +msgstr +Разрешить приложениям блокировать системную обработку +переключателя закрытия крышки I think it's an English-only idiom to talk about a switch here. So no переключателя. +#: ../src/timedate/org.freedesktop.timedate1.policy.in.h:7 +msgid Turn network time synchronization on or off +msgstr Включить/выключить синхронизацию с сетевым протоколом времени You don't synchronize with a protocol. Maybe: Включить/выключить синхронизацию времени по сети? -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-bugs] Russian translation for systemd
2013/11/14 Juliette Tux juliette@gmail.com: On 14 November 2013 19:10, Alexander E. Patrakov patra...@gmail.com wrote: I have never seen pretty translated as чудесный in such context (where the meaning is descriptive, meaningful). Could you please show some prior art? No, I'm afraid, this is kinda personal style. Haven't seen using 'pretty' by devs in messages very often either ;) Maybe just use a literal translation for this term? красивое название (name is intentionally translated differently, not as имя, but as название here, because host name without the word pretty is an idiom) -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Need help with a systemd/mdadm interaction.
2013/11/13 NeilBrown ne...@suse.de:
On Tue, 12 Nov 2013 19:01:49 +0400 Andrey Borzenkov arvidj...@gmail.com
wrote:
В Tue, 12 Nov 2013 21:17:19 +1100
NeilBrown ne...@suse.de пишет:
On Tue, 12 Nov 2013 18:16:24 +0900 Greg KH gre...@linuxfoundation.org
wrote:
On Tue, Nov 12, 2013 at 07:54:42PM +1100, NeilBrown wrote:
On Tue, 12 Nov 2013 00:10:28 -0800 Greg KH
gre...@linuxfoundation.org wrote:
On Tue, Nov 12, 2013 at 11:31:45AM +1100, NeilBrown wrote:
Alternately, is there some all devices have been probed, nothing
new will
appear unless it is hot-plugged event. That would be equally
useful (and
probably mirrors what hardware-RAID cards do).
No, there's no way to ever know this in a hotplug world, sorry.
Especially with USB devices, they show up when they show up, there's
no
oh look, the bus is all scanned now and all devices currently
plugged
in are found type knowledge at all.
Then there are hotplug PCI systems where people slam in PCI cards
whenever they feel like it (remember, thunderbolt is PCI express...)
Sorry,
greg k-h
Surely something must be possible.
For USB, nope, there isn't, sorry.
Clearly a physical hot-plug event will cause more devices to appear,
but
there must come a point at which no more (non-virtual) devices will
appear
unless a physical event happens?
Not for USB, sorry.
The USB bus just announces devices when it finds them, there is no all
is quiet type signal or detection.
Same for PCI hotplug, devices can show up at any point in time, you
never know when, and you don't know when all devices are found.
sorry,
greg k-h
Hmmm... OK. USB doesn't bother me a lot, but PCI is important.
I guess I'll just have to settle for a timeout much like the current
device-discovery timeout that systemd has.
Still hoping someone can tell me how to plug into that though...
If information about array name or other identification is available in
udev rule (I see reference to device node only) what you can do is to
start timer with now+5second (pick your timeout) that simply fires off
mdadm -IRs for specific array. Something like
mdadm-last-resort@.timer
[Timer]
OnCalendar=+5s
mdadm-last-resort@.service
[Service]
Type=oneshot
ExecStart=/sbin/mdadm -IRs %n
udev rule
... SYSTEMD_WANTS=mdadm-last-resort@$ENV{SOMETHING_UNIQUE}.timer
Thanks. This certainly looks interesting and might be part of a solution.
However it gets the timeout test backwards.
I don't want to set the timeout when the array starts to appear. I want to
set the time out when someone wants to use the array.
If no-one is waiting for the array device, then there is no point forcing it.
That's why I want to plug into the timeout that systemd already has.
Maybe that requirement isn't really necessary though. I'll experiment with
your approach.
It is useless to even try to plug into the existing systemd timeout,
for a very simple reason. in the setups where your RAID array is not
on the top of the storage device hierarchy, systemd does not know that
it wants your RAID array to appear.
So the statement If no-one is waiting for the array device, then
there is no point forcing it is false, because there is no way to
know that no-one is waiting.
--
Alexander E. Patrakov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/2] (dracut) hwdb needed in early boot for some keyboards
2013/11/13 Alexander E. Patrakov patra...@gmail.com: Colin Guthrie wrote: Hi, In this bug report https://bugs.mageia.org/show_bug.cgi?id=11645 a user is unable to enter their encrypted root password via a wireless keyboard connected with a Logitech, Inc. Unifying Receiver. Just in case, I do have the same model of wireless keyboard and will validate the bug (for the LUKS-password case) later today on my laptop. The keyboard does work on my desktop, but there's no initramfs there. I hereby confirm that the wireless Logitech keyboard works for entering the LUKS password on the laptop, if one does not create a host-only initramfs. This is with dracut-031. Some relevant kernel config bits: CONFIG_HID=y CONFIG_HID_GENERIC=y CONFIG_HID_LOGITECH=y CONFIG_HID_LOGITECH_DJ=m # dracut is smart enough to include it, even though the password entry works well without it CONFIG_USB_HID=m CONFIG_USB_XHCI_HCD=m CONFIG_USB_EHCI_HCD=m CONFIG_USB_EHCI_PCI=m -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/2] (dracut) hwdb needed in early boot for some keyboards
2013/11/13 Colin Guthrie gm...@colin.guthr.ie: 'Twas brillig, and Alexander E. Patrakov at 13/11/13 16:49 did gyre and gimble: 2013/11/13 Alexander E. Patrakov patra...@gmail.com: Colin Guthrie wrote: Hi, In this bug report https://bugs.mageia.org/show_bug.cgi?id=11645 a user is unable to enter their encrypted root password via a wireless keyboard connected with a Logitech, Inc. Unifying Receiver. Just in case, I do have the same model of wireless keyboard and will validate the bug (for the LUKS-password case) later today on my laptop. The keyboard does work on my desktop, but there's no initramfs there. I hereby confirm that the wireless Logitech keyboard works for entering the LUKS password on the laptop, if one does not create a host-only initramfs. This is with dracut-031. thanks for that. If it's easy enough for you to test, does it also work with a host-only initrd? It doesn't, because (at least whe creating the initramfs without the USB keyboard connected) it does not include the usbhid module. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/2] (dracut) hwdb needed in early boot for some keyboards
2013/11/13 Colin Guthrie gm...@colin.guthr.ie: What about if you generate it with the keyboard plugged in? It should include the usbhid module then, but does it actually work? Will try a bit later, but I suspect this is the wrong direction of thought. The problem we're encountering is that even with the usbhid module included in the host-only initrd, it still doesn't work - even after manually modprobing it from a ps/2 keyboard. All modules that are needed for the user's keyboard are included in the initrd. As I don't have the h/w I cannot tell what component is missing to make it all work. I'm currently suspecting some kind of usb host controller interface driver or something, but have yet to hear back from the user so any insights or info you have would be appreciated. I'd suspect something related to USB power saving. This is the most frequent reason for USB keyboards and mice to misbehave - the host just turns them off mistakenly. So /lib/udev/rules.d/42-usb-hid-pm.rules does look relevant. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/2] (dracut) hwdb needed in early boot for some keyboards
2013/11/13 Alexander E. Patrakov patra...@gmail.com: 2013/11/13 Colin Guthrie gm...@colin.guthr.ie: What about if you generate it with the keyboard plugged in? It should include the usbhid module then, but does it actually work? Will try a bit later, but I suspect this is the wrong direction of thought. A host-only initramfs generated with the USB keyboard plugged in works. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/2] (dracut) hwdb needed in early boot for some keyboards
2013/11/14 Colin Guthrie gm...@colin.guthr.ie: What kernel are you using out of interest? This kernel is a git snapshot between 3.12.0-rc2 and -rc3. Compiled on Gentoo. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Need help with a systemd/mdadm interaction.
NeilBrown пишет:
On Wed, 13 Nov 2013 22:11:27 +0600 Alexander E. Patrakov
patra...@gmail.com wrote:
2013/11/13 NeilBrown ne...@suse.de:
On Tue, 12 Nov 2013 19:01:49 +0400 Andrey Borzenkov arvidj...@gmail.com
wrote:
Something like
mdadm-last-resort@.timer
[Timer]
OnCalendar=+5s
mdadm-last-resort@.service
[Service]
Type=oneshot
ExecStart=/sbin/mdadm -IRs %n
udev rule
... SYSTEMD_WANTS=mdadm-last-resort@$ENV{SOMETHING_UNIQUE}.timer
Thanks. This certainly looks interesting and might be part of a solution.
However it gets the timeout test backwards.
I don't want to set the timeout when the array starts to appear. I want to
set the time out when someone wants to use the array.
If no-one is waiting for the array device, then there is no point forcing it.
That's why I want to plug into the timeout that systemd already has.
Maybe that requirement isn't really necessary though. I'll experiment with
your approach.
It is useless to even try to plug into the existing systemd timeout,
for a very simple reason. in the setups where your RAID array is not
on the top of the storage device hierarchy, systemd does not know that
it wants your RAID array to appear.
So the statement If no-one is waiting for the array device, then
there is no point forcing it is false, because there is no way to
know that no-one is waiting.
useless seems a bit harsh. not-optimal may be true.
If systemd was waiting for a device, then it is clear that something was
waiting for something. In this case it might be justified to activate as
much as possible in the hope that the important things will get activated.
This is what mdadm -IRs does. It activates all arrays that are still
inactive but have enough devices to become active (though degraded). It
isn't selective.
If they are deep in some hierarchy, then udev will pull it all together and
the root device will appear.
If systemd is not waiting for a device, then there is no justification for
prematurely starting degraded arrays.
Maybe I could get emergency.service to run mdadm -IRs and if that actually
started anything, then to somehow restart local-fs.target. Might that be
possible?
If this is the way forward, then we, obviously, should think about a
general mechanism that is useful not only for mdadm, but also to other
layered storage implementations such as dm-raid, or maybe multi-device
btrfs, and that is useful if more than one of these technologies are
used on top of each other. This by necessity leads to multiple emergency
missing-device handlers. And then a question immediately appears, in
which order the emergency handlers should be tried, because all that is
known at the time of emergency is that some device listed in /etc/fstab
is missing. I suspect that the answer is in arbitrary order or even
in parallel, but then there is a chance that one run of all of them
will not be enough.
This is not a criticism, just something to be fully thought out before
starting an implementation.
--
Alexander E. Patrakov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/2] (dracut) hwdb needed in early boot for some keyboards
Colin Guthrie wrote: Hi, In this bug report https://bugs.mageia.org/show_bug.cgi?id=11645 a user is unable to enter their encrypted root password via a wireless keyboard connected with a Logitech, Inc. Unifying Receiver. Just in case, I do have the same model of wireless keyboard and will validate the bug (for the LUKS-password case) later today on my laptop. The keyboard does work on my desktop, but there's no initramfs there. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd fails to build with static kmod library
2013/6/4 Lennart Poettering lenn...@poettering.net:
On Mon, 03.06.13 00:52, Stephan Raue (mailingli...@openelec.tv) wrote:
Am 02.06.2013 19:36, schrieb Greg KH:
On Sun, Jun 02, 2013 at 07:28:57PM +0200, Stephan Raue wrote:
i dont agree, i some cases it makes sense. since udev is included in
systemd and udev has now its own buildins for the modprobe stuff it
should be possible to use kmod statically linked, esp. if no other
installed program uses kmod (and for our usage the kmod userspace
binarys are not neccessary)
If you are so worried about other programs / users calling kmod, then
just build your needed kernel modules into the kernel and don't use any
kernel modules at all.
i am not much worried about this, but more about the comment Do not
use static linking, with systemd, ever, in fact do not use with any
other component.. Statically linking works for so many programs and
even kmod supports the --enable-static configure option. So
basically i tried to report this broken behavior, because i never
seen a statement like dont link anything statically against
systemd
Static linking is broken for many reasons. One reason is the namespace
issue you ran into.
I think that there is some misunderstanding of the complaint here,
caused by libtool. Basically, I think that the complaint is: you
provide the --enable-static option, so it should work, even though it
is not the default. Here is what really happens:
1. systemd's (and kmod's) configure.ac uses the LT_INIT macro that
comes from libtool. It is useful for building shared libraries.
2. That macro, among other things, teaches the configure script to
understand the --{en,dis}able-{static,shared} options.
3. Due to reasons already mentioned in this thread, static linking
should not be used for systemd and kmod.
4. The LT_INIT macro has a way to disable the build of static
libraries by default (but the user who runs the configure script can
override this default), and systemd does that.
5. This macro does not have a way to forcibly disable the build of
static libraries.
(5) is a bug in libtool. There is nothing systemd can do about it.
--
Alexander E. Patrakov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/6] nss-myhostname: integrate into systemd buildsystem
2013/1/8 Bryan Kadzban br...@kadzban.is-a-geek.net: I *suppose* that might be because pkg-config or some equivalent fixes it up somehow, pointing to the .la files directly. Or maybe -L affects this somehow. The -L option does have an effect on this. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: Predictable Network Interface Names
2013/1/8 Lennart Poettering lenn...@poettering.net: Heya, a few days ago Kay commited a change to git that made predictable network interface names the default for the upcoming systemd/udev 197. To explain what this is about we put together this wiki document: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames Please have a look, it's a first version, so might grow a bit in the next days, but should already be quite complete. It's supposed to explain the Why? and the How-do-I-get-rid-of-this? among other things. Very good! However, a wording about userspace trying to assign the interface name raced against the kernel assigning new names is not good enough, from my viewpoint. The end result is that the old persistent names failed to apply during some boots. Hiding that under all kinds of weird effects does not do the reader any good. In addition, I'd like to see the design objectives factored out and listed as buttet points, maybe in a separate section, e.g.: * Stable intarface names accross reboots (obviously) * Stable intarface names accross hw addition/removal * Stable intarface names accross kernel versions * Stateless operation * Compatibility with read-only root * Peaceful coexistence with vlans, bridges, bonds and other kinds of virtual interfaces * Extensibility of the scheme (think about firewire interfaces - we can just reserve a letter for them in the path) * Applicability to both x86 and non-x86 machines * Being a cross-distribution standard * Easiness to opt out of the scheme i.e. imagine that you are writing a US patent, don't be afraid of essentially duplicate entries. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/6] nss-myhostname: integrate into systemd buildsystem
2013/1/7 Bryan Kadzban br...@kadzban.is-a-geek.net: Untrue. They're perfectly useful for dynamic linking as well: http://www.sourceware.org/autobook/autobook/autobook_68.html#SEC68 Second paragraph. Also the page several sections after this one, about installing a shared library with libtool. Unfortunately, on linux, libtool's la files are actively harmful for multilib setup and _must_ be removed (ideally, upstream) if possible. They represent an unsolvable problem in the following case: * you are on amd64 * libfoo is built both as 64-bit and 32-bit library and has a *.la file at least in in /usr/lib64 * you are trying to link a 32-bit program as follows: libtool --mode=compile --tag=CC gcc -m32 test.c -c -o test.lo libtool --mode=link --tag=CC gcc -m32 test.lo -lfoo -o test If /usr/lib64/libfoo.la exists, then libtool will pick it up and feed /usr/lib64/libfoo.so to gcc instead of just -lfoo. As a result, the linker will barf because of the incompatible architecture. I.e. stupid libtool duplicates the gcc library search logic, but doesn't realize that -m32 alters the library path and that the first library found may not be the one that is usable. Surely you don't want create a problem for distributions that want to build various systemd libraries both for 64 and 32 bits, do you? AFAIK RedHat works around this: https://bugzilla.redhat.com/show_bug.cgi?id=138742 but the patch has never been pushed upstream. See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655450 -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: integrate biosdevname into systemd tree
2013/1/4 Reindl Harald h.rei...@thelounge.net: but hopefully /etc/udev/rules.d/70-persistent-net.rules will be recognized forever if it exists because there are many servers especially virtual ones where you hardly need to control ethernet device names to avoid breaking iptables-scripts as example Yes, the existing rules will continue to be recognized. The bug is that even they are intrinsically unreliable (as happened with that rented server), so I think you actually don't want that. keep in mind there are MANY setups which do not need nor want biosdevname and are bootet with biosdevname=0 on the kernel line And that's indeed something that we need to think about. The real problem is that it is hard to explain the whole interface-renumbering issue and the reasons why he needs persistence to an average sysadmin. It's too low level. IMHO it is safer to always install biosdevname and use it even if not strictly required than to rely on the sysadmin to know about the issue. For me, even with the old solution in place, the bug surfaced after ~10 reboots. That's more than an average sysadmin is willing to test before saying I think it always boots as it should. Besides, the sysadmin can be wrong about not needing the persistent names. Again, my position is: better safe than sorry, especially with remotely-managed servers. P.S.: i HATE it to need ifconfig -a and hack 70-persistent-net.rules by hand instead as all the years open it and change back the last line to eth0 after probe-restore of a virtual machine to temporary access a datarecovery backup from some weeks ago With biosdevname, the interface names are determined only by PCI bus slot. I.e., if the replacement card is inserted into the same slot as the failed one, the name won't change. And in virtual machines biosdevname deactivates itself automatically. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: integrate biosdevname into systemd tree
2013/1/4 Reindl Harald h.rei...@thelounge.net:
how can something like this be unreliable?
hwaddresses does not change randomly
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==00:50:56:bd:00:04, ATTR{dev_id}==0x0,
ATTR{type}==1, KERNEL==eth*, NAME=eth0
Good question, and it hits the very core of the problem. I don't know
the answer, maybe we should wait for Kay or Lennart to explain that. I
only know that it IS unreliable if the following renames have to be
the end result:
[removed card] - eth0 (non-existing)
eth0 - eth1
eth1 - eth2
and it is claimed to be reliable for the case when the destination
names are not eth*, e.g.:
eth0 - lan
eth1 - wan
currently syaadmins who knew over years how to handle
70-persistent-net.rules are more pissed of than ever before
Yeah, resistance to ANY change is an integral part of a human nature.
And it also makes a good sysadmin. The problem, as stated multiple
times, is that same-namespace renames do not work reliably, cannot
work reliably, and that the official preferred solution (yet to be
drilled into sysadmins' brains) now is to avoid them completely.
you are missing the real problem with the new shiny biosdevname
nobody can rely on eth0 any longer
Yes, that's a problem.
if have thousands of firewall-scripts and configurations which
are assuming eth0=LAN, eth1=WAn as example, the benefit of such
scripts is that they can be easily adopted to a new but compareable
setup and basic rules are always the same
You can achieve the same by manually writing the equivalent of the
persistent rules by hand, just don't name the renamed interfaces eth*.
Existing rules override what biosdevname thinks. And you can use
variables like $LAN and $WAN in the scripts.
--
Alexander E. Patrakov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ExecRestart
Brandon Black blbl...@gmail.com wrote: The daemon's fast restart code does all of the expensive startup operations in the new daemon first (e.g. parsing large data input), then signals the existing daemon to shut itself down, waits for it to release its critical resources (e.g. sockets, pidfile), and finally takes over those resources and finishes starting itself. Basically it's using the overlap to avoid long service downtimes during that initial parsing phase (and if that parsing fails, it leaves the old daemon running to boot). This is not what a restart means in systemd world. What you described is just a nice way to do a reload. However, as the main pid changes during this reload, please be careful - several years ago that would hit an assertion in systemd, and due to my aziness I have not verified the fix. -- Alexander E. Patrakov Sent from Nokia N900 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] logind lid switch inhibitors
David Herrmann dh.herrm...@googlemail.com wrote: I don't use any DEs but often close the lid while some background job is running (compiler or whatever). Do you do that while on battery? If not, then I'd say that a good idea would be to suspend only if closing the lid while on battery, or if removing AC power while the lid is closed. Would that be OK for you? -- Alexander E. Patrakov Sent from Nokia N900 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cryptsetup on FakeRAID fails with timeout
2012/9/17 Ali Lown a...@lown.me.uk: I am unable to get systemd to mount a LUKS partition on boot. This LUKS partition (pdc_bhjchdjgaep5) sits on top of a fakeraid mirror set (pdc_bhjchdjgae) of 2TB disks (sdd,sde). Disclaimer: what I am proposing below is not a solution, just a workaround. Now that a normal md raid is able to assemble fake RAIDs perviously handled by dmraid, could you please try to migrate? Just try to assemble md raid as usual, obviously without having run dmraid. You'll get devices like md126_p1 and md126_p2. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Starting Display Managers
Hello. Several days ago I stumbled upon an interesting race condition (which is not a bug in systemd) that I want to share now. To reproduce: install lxdm, and the following (buggy) unit to start lxdm on boot: [Unit] Description=LXDE Display Manager [Service] ExecStart=/usr/sbin/lxdm # After each successful logout, lxdm terminates Restart=on-success [Install] WantedBy=graphical.target Note that, as compared to the Arch Linux unit, this misses the dependency on systemd-user-sessions.service, but in fact the race condition is deeper. The problem is that lxdm starts the X server, and it has certain /dev requirements that vary with hardware and, at least from my first impression, not known in advance. If the user has a graphics card supported by open-source DRI-based drivers with mandatory KMS, then /dev/dri/card0 (or maybe card1 in dual-gfx setups) is needed. And for Radeon TURKS cards, this only appears after loading firmware (which takes some time). If this is a tablet using the fbdev driver, then /dev/fb0 is needed. And with yet-unsupported graphics cards, the vesa driver only needs /dev/mem or something like that which is always present given a devtmpfs. The question is: how does one write this dependency information, so that lxdm is not attempted to be started before udev creates the necessary device node? Yes, I understand that GPU hotplug in Xorg is the real answer, but we don't have that now, and I don't know how it would cover vesa-based screens. This is not exactly a theoretical question. While I could not reproduce this race using a RAID0 setup made from two Samsung SATA-III SSDs, it does trigger reliably (even with an Intel card) if one puts the entire system into an initramfs and makes the /init - usr/bin/systemd symlink. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Thoughts on adapting daemons to use socket activation
2012/8/21 Lennart Poettering lenn...@poettering.net: On Sat, 18.08.12 16:04, David Strauss (da...@davidstrauss.net) wrote: Additionally, socket activation could get rather interesting capability if there were a middle-ground between single process per connection and one process for all connections. Frameworks like Twisted Python and node.js have built their own wrappers to do this in various kludgy ways that involve a master process opening the main socket and then passing file descriptors or other structures into the fork()ed processes or using separate load balancers to spread the requests out. This might be totally out of scope for systemd, though. Hmm, so this would mean systemd would spawn multiple instances of a service binary, but pass all of them the listening socket? Interesting idea. We could probably do that, but we couldn't dynamically know how many worker processes to spawn, since we wouldn't know how much entries are queued unprocesse on the socket... Or maybe, there is an ioctl/sockopt for that? Definitely an interesting idea... No need to configure this dynamically. This is supposed to be an option configured statically by the sysadmin via a configuration file (a service file?), just like the ServerLimit and MaxClients apache2 config directives. And the whole things looks very much like apache2 preform MPM. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Thoughts on adapting daemons to use socket activation
2012/8/21 Alexander E. Patrakov patra...@gmail.com: 2012/8/21 Lennart Poettering lenn...@poettering.net: On Sat, 18.08.12 16:04, David Strauss (da...@davidstrauss.net) wrote: Additionally, socket activation could get rather interesting capability if there were a middle-ground between single process per connection and one process for all connections. Frameworks like Twisted Python and node.js have built their own wrappers to do this in various kludgy ways that involve a master process opening the main socket and then passing file descriptors or other structures into the fork()ed processes or using separate load balancers to spread the requests out. This might be totally out of scope for systemd, though. Hmm, so this would mean systemd would spawn multiple instances of a service binary, but pass all of them the listening socket? Interesting idea. We could probably do that, but we couldn't dynamically know how many worker processes to spawn, since we wouldn't know how much entries are queued unprocesse on the socket... Or maybe, there is an ioctl/sockopt for that? Definitely an interesting idea... No need to configure this dynamically. This is supposed to be an option configured statically by the sysadmin via a configuration file (a service file?), just like the ServerLimit and MaxClients apache2 config directives. And the whole things looks very much like apache2 preform MPM. Forgot to say: feel free to ignore the self-regulating nature of the prefork MPM advertised at http://httpd.apache.org/docs/2.2/mod/prefork.html. Just preforking a fixed number of processes sharing the same listening socket is good enough in some (most?) cases. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] add keyscript support to cryptsetup
2012/7/10 Lennart Poettering lenn...@poettering.net: Well, but if this is all dependent on some other hw then the synchronous nature of keyscript= doesn't work anyway... (see other mail about that) From a user point of view it is of course additional flexibility which is the usecase. I've seen keyscripts to use Yubikeys, keyscripts to get keys off a smartcard (and the PIN for the smartcard could be requested via systemd passwordagents or any other scheme), scripts which mount different filesystems and grab the key off them, etc. Both yubikeys and most smartcard readers are USB devices, so you always have the enumeration issues, which means a synchronous solution wouldn't work wihtout races anyway and the async agent stuff is much preferable. http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents I also dislike additional complexity and realize that systemd is an excellent oppurtinity of providing some much needed spring cleaning in distribution-specific boot scripts - but there are a few problems with using password agents: Well, the complexity comes for a reason: correctness. I understand your position about the racy code, but want to point you to http://thecodelesscode.com/case/9 . In the spec, there is indeed no way to wait until all USB devices show up. In practice, if the key does not show up in, say, 10 seconds (of course this timeout value should not be in the kernel), it is not there, period, from all sane user viewpoints. IMHO a theoretical race that is never triggered in user-relevant cases is preferrable to the complexity required to get everything mathematically right and to the lack of a well-defined policy for getting the key is not there, panic error message. The new asynchronous password agent interface does not help against races without an easy way to say this password agent (or even: this encrypted volume) needs yubikey and fail with an error message explicitly mentioning yubikey if yubikey didn't show up for 10 seconds. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] timed events
2012/6/29 David Strauss da...@davidstrauss.net: snip suggestions Having a timer-based service start/stop bgpd.service works fine. I just wanted to offer a dependency-based take. Thanks. Both suggestions are strictly better than the paper note based solution, and your reply does prove that nothing needs to be changed in systemd to get the effect I want. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] timed events
2012/6/29 Kok, Auke-jan H auke-jan.h@intel.com: On Fri, Jun 29, 2012 at 12:49 AM, Nathan qwerty@gmail.com wrote: Another issue (though slightly related) is we have an external binary that when run will return 0 or 1 depending if we should run a service is there a way to run this command in the service_name.service and start the service if it returns 0 and stop the service if the script returns 1 (retrying the script every 5 minutes or so). cheap trick: make a script and run it from a timer, have the script run `systemctl ...` better trick: fix the daemon to do all of this properly. Hello. The company I work for has a similar need. The director has permitted me to disclose the details in full, in hope that this will permit you to understand the use case better and understand why fix the daemon is not a possible solution in our case. We are not using systemd yet on our servers, but this doesn't make the problem statement invalid. We have several servers hosted at different ISPs, and our own autonomous system. The service is provided to our clients via IPv4 anycast. So, at each of the servers, we run bgpd (from quagga) and announce a route to our own IPv4 block. This means that each client will be routed to the nearest (in the BGP sense) server. It also protects our service against outages that affect the entire ISP, and allows us to perform maintenance and software upgrades safely (i.e. with near zero visible downtime for clients) by stopping bgpd first. The issue is that twice in the company's lifetime there was a payment problem with one of the servers. When this happened, the ISP did not shut down the affected server. Instead, they somehow firewalled the packets destined to it, but the BGP session was left intact. End result: the route is still announced into the global routing table, but doesn't work, and some clients see service interruption. So, as a protection against such mistakes, we need some form of a custom dead man's switch that would stop bgpd if none of the test IPv4 addresses is pingable. Of course, such monitoring need is specific to our use case, and other companies will either not need it at all or write a dead man's switch with a different logic. So the logic, as I understand it, should be as follows: run bgpd if the administrator has not prohibited this due to maintenance or similar reasons, and the periodically-executed (?) dead-man's-switch script doesn't say that bgpd should not run. The run systemctl from timer is close, but not close enough: extra care is needed during maintenance periods to disable the dead man's switch script (so it doesn't restart bgpd contrary to the administrator's decision) and not to forget to reenable it later. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 'Offline System Updates' examination
2012/6/21 Lennart Poettering lenn...@poettering.net: On Wed, 20.06.12 22:23, Antonio Trande (anto.tra...@gmail.com) wrote: 'Offline System Updates' will come as feature for Fedora 18. Reading your official page http://freedesktop.org/wiki/Software/systemd/SystemUpdates: The system update script now creates a btrfs snapshot (if possible), then installs all RPMs. After completion (regardless whether the update succeeded or failed) the /system-update symlink is removed. In addition, on failure it reverts to the old btrfs state (modulo the aforementioned symlink), on success it leaves the newly made changes in place. BTRFS ? Will 'Offline Updates' be available only with BTRFS ? Nope. But on btrfs we'll make a snapshot of the old system state. On non-btrfs we won't. As far as I understand from the design document, both on btrfs and on ext4 the sequence is: 1) Download updates 2) Reboot into a minimal environment (system-update.target), make a snapshot if the FS supports it 3) Install updates automatically 4) Reboot And I have two questions about that: 1) Can one configure the system to use kexec instead of the reboot? (BTW, the only machine that I have access to and where kexec doesn't work is a multi-CPU KVM guest) 2) Did anyone consider a plan to do updates on ext4 and btrfs differently? E.g. one can use the same sequence as above for ext4 and make a writable snapshot, install to snapshot, reboot with that snapshot as root on btrfs. This, theoretically, has a huge advantage of being able to work on on source-based distributions like gentoo (unlike the original sequence, which means at least 1 hour of complete downtime due to compilation of LibreOffice at step 3). -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 'Offline System Updates' examination
2012/6/21 Lennart Poettering lenn...@poettering.net: If source based distros want to implement this I'd probably recommend them to compile everything in the system, and only do the final step, the installation as part of the system-update step. The problem is that your recommendation (if I understand it correctly) does not work, at all. Suppose that there are two packages to update, icu and libreoffice. Libreoffice depends on icu, and for the reason of simplicity of the argument let's pretend that there are no other packages in the system that use icu. If your recommendation is to be followed literally, the package manager needs to compile icu (thus creating either a binary package or a tree where it can run make install later), compile libreoffice the same way, then install both results later. However, this would lead to installation of libreoffice compiled against the old icu, which may or may not work. Libreoffice should really be compiled with the new icu already installed, and this is directly against the install all updates in one big batch approach. So, could you please clarify the recommendation in the aspect of dealing with such dependencies? The install to btrfs snapshot approach would handle this correctly by installing each package as soon as it gets compiled. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 'Offline System Updates' examination
2012/6/21 Lennart Poettering lenn...@poettering.net: But this looks like a limiation of the build system, no? The build system should be capable of building against a non-installed version. The binary distro auto builders can do that... In Debian, they do that by installing all dependencies of a to-be-built package into a chroot, which for our purposes is exactly equivalent to installation to a writable snapshot. In fact, their cowbuilder can use LVM snapshots, too. I don't know how this is implemented in Fedora, any pointers? I think this really should be fixed in the build system, not in the system-update.target logic. Point taken, and you are right that the system-update.target logic is a bad place to solve it. What I was talking about (when mentioning installation to a snapshot as an alternative possibility of offline updates) indeed does not need any support from systemd - just the ability of the package manager to set a different btrfs root mount option for next boots. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ssh socket activation (Was: systemd unit files for Debian based systems)
2012/6/19 Lennart Poettering lenn...@poettering.net: On Tue, 19.06.12 18:50, Michael Olbrich (m.olbr...@pengutronix.de) wrote: Hi, On Tue, Jun 19, 2012 at 10:03:23AM +0200, Lennart Poettering wrote: On Mon, 18.06.12 21:56, Paul Menzel (paulepan...@users.sourceforge.net) wrote: Do you know of a service file for openssh-server? The Fedora packages have some, but I don't like them too much since they don't use socket activation... Is someone actually working on real socket activation for openssh? While the inetd like stuff works, it does not perform well. it doesn't? In which way? It should be totally OK? IMHO there is one issue with the inetd-style approach: it is explicitly discouraged in man sshd. It may well be the case of outdated documentation, as I don't see any of the indicated problems on my desktop or laptop. Still, it would be nice to clarify this discrepancy in the unit file. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] wpa_supplicant: Add systemd support
Lennart Poettering wrote: On Tue, 12.07.11 16:20, Henry Gebhardt (hsggebha...@googlemail.com) wrote: (To the hostap mailing list: I wasn't subscribed to this list when I sent the patches, now I am. Did they reach you?) On Mon, Jul 11, 2011 at 10:13:52PM +, Alexander E. Patrakov wrote: This is not enough to get a working wpa_supplicant on a wired interface that uses 802.1X - we need -Dwired in this case. I wasn't even aware that possibility existed. :) Do you think it makes sense to provide a unit file for each of the driver options? I'm rather thinking that providing a template that works for the most common setups may be sufficient. Isn't there an option to add to wpa_supplicant to autodetect this setting? For example -Dauto or so? Or just leaving it out entirely? Unfortunately, I can't really test, because I currently have no access to any real network where this technology is in use. However, my limited testing with virtual machines and wireshark shows that there seems to be no valid option that leads to correct driver autodetection and network registration both on my wireless card and on virbr0. The closest thing I got was -Dnl80211,wired - it selected nl80211 on wireless and selected wired on virbr0. However, the iwlagn driver has a bug: it doesn't associate to IBSS networks when used through nl80211, so this is not a 100% workable solution for me (I am willing to debug and test any patches sent to my email address). -Dwext,wired doesn't work - the wext driver is not smart enough to give up on non-wireless interfaces. So indeed, a separate unit file as sent with v2 of the patch is the necessary evil. One more thing: the service fails (because wpa_supplicant exits unsuccessfully) if the hardware rfkill switch is off. But this is not a regression as compared to the current cituation with OpenRC, so it is not an objection for the patch. IMHO a wait for rfkill to go away switch is wanted for wpa_supplicant, but it currently doesn't exist. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] wpa_supplicant: Add systemd support
Henry Gebhardt wrote: --- /dev/null +++ b/wpa_supplicant/systemd/wpa_supplicant@.service @@ -0,0 +1,11 @@ +[Unit] +Description=WPA supplicant daemon (interface-specific version) +# NetworkManager users will probably want the dbus version instead. +[Service] +Type=simple +ExecStart=/sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf -i%I +[Install] +Alias=network.target.wants/wpa_supplicant@wlan0.service This is not enough to get a working wpa_supplicant on a wired interface that uses 802.1X - we need -Dwired in this case. Also, there is a use case for two wpa_supplicants on two interfaces, with different configs: one for normal wireless, one for wired 802.1X, with different interface metrics. Your service file doesn't support this. And finally, how do you guarantee the correct ordering - i.e. that wpa_supplicant should not start before the interface appears? -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Assertion failed in systemd v16
18.01.2011 04:14, Lennart Poettering пишет: On Mon, 10.01.11 15:11, Alexander E. Patrakov (patra...@gmail.com) wrote: [Unit] Description=Lighttpd Web Server After=network.target [Service] Type=forking EnvironmentFile=/etc/conf.d/lighttpd PIDFile=/var/run/lighttpd.pid ExecStartPre=/usr/sbin/lighttpd -t -f /etc/lighttpd/lighttpd.conf Hmm, whiy is this necessary? I presumee starting the daemon will do an implicit configuration check anyway, right? I mean, how could it load the config without checking for its validity? Indeed, my bad. ExecStart=/usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf ExecStop=/bin/kill -INT $MAINPID This is asynchronous. The stop operation is supposed to be synchronous however, should not return before it finished. This was modeled after the existing apache2 service file in gentoo systemd overlay, which uses graceful asynchronous stop. If you delete the ExecStop line, systemd will use SIGTERM (non-graceful stop) and wait. That's probably what you want the stop operation to be. OTOH, like it or not, too many existing services don't have any mechanism for synchronous reload and use SIGHUP. I think you should audit all existing service files in Gentoo systemd overlay to ensure that I don't copy any more bad practice. See http://git.overlays.gentoo.org/gitweb/?p=user/systemd.git;a=summary As you noticed, this changes the PID, and systemd currently cannot handle this. We could however reload the PID file after a reload completed I guess. (/me adds this to the todo list) Well, there are cases (live update of nginx, see http://wiki.nginx.org/NginxCommandLine#Upgrading_To_a_New_Binary_On_The_Fly) where the main PID would change without the explicit systemctl reload command. In the case of nginx, one can follow up the live update with a dummy systemctl reload, so I am not sure if it matters. OTOH, maybe it would be better to evaluate the main PID lazily when it is needed, instead of trying to enumerate all places where it can change and reloading it there. But this way we will also hide all races caused by bad PID file handling logic, so I am not sure. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] lighttp unit - graceful reload of configfiles by sending signal to $MAINPID
18.01.2011 04:48, Lennart Poettering wrote: What systemd currently does is: If the reload fails it shutdowns the service and informs you about the failure. What systemd probably should do (and what is now in the TODO list) is: If the reload fails it should leave the service as is but informs you about the failure. That should make it easy to plug in check scripts via the ExecReload directive and make the need of an additional directive unnecessary. For the case of reloading, you are right. However, the original idea was to run the configuration check also on restart (but not on stop). It is not obvious for me how this can work without a new directive. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Restarting sshd
Hello. I have sshd-related unit files from http://0pointer.de/public/systemd-units/ sshd.service has the following problem, which is a regression from a traditional SysV setup and which is not present in sshd.socket + s...@.service. Yes, I know that the use of this service is discouraged. The problem is that one can no longer safely restart sshd while connected via ssh. If one attempts to do so via systemctl restart sshd.service, all ssh sessions become disconnected. Also, the service cannot be reloaded except by sending SIGHUP to the sunning sshd manually. So, I propose the following improved version of sshd.service, with the ability to reload the service, with safety regarding systemctl restart sshd.service, and with protection against crashes: [Unit] Description=SSH Secure Shell Service After=syslog.target [Service] ExecStart=/usr/sbin/sshd -D KillMode=process Restart=always ExecReload=/bin/kill -HUP $MAINPID [Install] WantedBy=multi-user.target # Note that this is the service file for running a single SSH server for all # incoming connections, suitable only for systems with a large amount of SSH # traffic. In almost all other cases it is a better idea to use sshd.socket + # s...@.service (i.e. the on-demand spawning version for one instance per # connection). -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Restarting sshd
11.01.2011 15:24, Miklos Vajna wrote: Is there any chance this could be sumitted to the maintainers of the portable openssh? Having a different version for each distro is not something we want for sure. Sorry, I am afraid I won't manage it. Is there any existing success story of service file submission recorded in any mailing list? Basically, I want some mail to use as a template. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] lighttp unit - graceful reload of configfiles by sending signal to $MAINPID
10.01.2011 22:49, Marius Tolzmann wrote: hi.. can the initial problem of restarting the lighttpd gracefully be solved by something like this?: Restart=on-success ( or on-abort or always .. don't know what the exit-status after graceful kill is in lighty) After more research, I found the under-documented lighttpd-angel program. It does what is needed for babysitting lighttpd: performs the send SIGINT to the old copy and immediately start the new one dance when it receives SIGHUP. See http://blog.lighttpd.net/articles/2007/09/02/there-is-an-angel-for-lighty . So here is a working unit file for lighttpd, with graceful reloading: == [Unit] Description=Lighttpd Web Server After=network.target [Service] ExecStart=/usr/sbin/lighttpd-angel -f /etc/lighttpd/lighttpd.conf -D ExecReload=/bin/kill -HUP $MAINPID [Install] WantedBy=multi-user.target WantedBy=http-daemon.target == While this works, it looks somehow ugly because of a special lighttpd-angel program that only launches and restarts lighttpd (i.e., performs a job that is IMHO more suited for systemd) - but well, lighttpd's requirements are special. Here is what it looks like normally: home ~ # systemctl status lighttpd.service lighttpd.service - Lighttpd Web Server Loaded: loaded (/etc/systemd/system/lighttpd.service) Active: active (running) since Tue, 11 Jan 2011 15:46:50 +0500; 1s ago Main PID: 12659 (lighttpd-angel) CGroup: name=systemd:/system/lighttpd.service ├ 12659 /usr/sbin/lighttpd-angel -f /etc/lighttpd/lighttpd.conf -D └ 12660 /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf -D Here is what it looks like during graceful restart: home ~ # systemctl status lighttpd.service lighttpd.service - Lighttpd Web Server Loaded: loaded (/etc/systemd/system/lighttpd.service) Active: active (running) since Tue, 11 Jan 2011 15:46:50 +0500; 58s ago Process: 12670 (/bin/kill -HUP $MAINPID, code=exited, status=0/SUCCESS) Main PID: 12659 (lighttpd-angel) CGroup: name=systemd:/system/lighttpd.service ├ 12659 /usr/sbin/lighttpd-angel -f /etc/lighttpd/lighttpd.conf -D ├ 12660 /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf -D └ 12671 /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf -D And here is the final status when the long transfer which kept PID 12660 busy is finished: home ~ # systemctl status lighttpd.service lighttpd.service - Lighttpd Web Server Loaded: loaded (/etc/systemd/system/lighttpd.service) Active: active (running) since Tue, 11 Jan 2011 15:46:50 +0500; 1min 41s ago Process: 12670 (/bin/kill -HUP $MAINPID, code=exited, status=0/SUCCESS) Main PID: 12659 (lighttpd-angel) CGroup: name=systemd:/system/lighttpd.service ├ 12659 /usr/sbin/lighttpd-angel -f /etc/lighttpd/lighttpd.conf -D └ 12671 /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf -D If you also want graceful stop, you may want to add: ExecStop=/bin/kill -INT $MAINPID but this doesn't work, as lighttpd gets killed immediately. I don't know why this happens. Also, the test config before reloading feature still doesn't work right. If I add this ExecReload line before the existing one: ExecReload=/usr/sbin/lighttpd -t -f /etc/lighttpd/lighttpd.conf then systemd will kill lighttpd-angel when the configuration file is bad. It should instead complain to syslog and do nothing with the running instances of lighttpd and lighttpd-angel. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] ExecConfigTest first try
11.01.2011 21:11, Mirco Tischler wrote: a patch Sorry, this doesn't work as expected. To reproduce the problem: 1) Start a service with a good config 2) Edit the config. Make a typo. 3) Attempt to reload the service. At this point, systemd will put the whole service into a failed state. 4) Fix the typo. 5) Attempt to reload the service. Expected result: service reloaded with the new config. Actual result: systemd doesn't let me reload the service. Also, when starting a service, systemd tests the config twice for some reason. And it is really strange that in the system log with systemd.log_level=debug systemd.log_target=kmsg, systemd attempts to fork the main command before the check finished and thus seems to run the main command in parallel with the check. In other words, I doubt that the correct thing is tested. I suspect that the executable is found fact is tested, not the command executed successfully. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Assertion failed in systemd v16
I wrote: Here is what happened when I tried to reload lighttpd while looking with strace whan systemd is doing: [ 3639.047649] systemd[1]: Assertion 's-control_command_id == SERVICE_EXEC_START' failed at src/service.c:2184, function service_run_next_main(). Aborting. [ 3639.052182] systemd[1]: Caught ABRT, dumped core as pid 6045. [ 3639.052376] systemd[1]: Freezing execution. I could not reproduce the bug without stracing systemd: strace -ff -e process -p 1 Now I can reproduce it more reliably without strace. Here is the slightly modified service file: [Unit] Description=Lighttpd Web Server After=network.target [Service] Type=forking PIDFile=/var/run/lighttpd.pid #ExecStartPre=/usr/sbin/lighttpd -t -f /etc/lighttpd/lighttpd.conf ExecStart=/usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf ExecStop=/bin/kill -INT $MAINPID #ExecReload=/usr/sbin/lighttpd -t -f /etc/lighttpd/lighttpd.conf ExecReload=/bin/kill -INT $MAINPID ExecReload=/bin/sleep 1 ExecReload=/usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf StandardOutput=syslog StandardError=syslog [Install] WantedBy=multi-user.target WantedBy=http-daemon.target To reproduce, I just have to do some attempts of start, stop, start again, reload actions, with 30-second pauses between them. Reproduction is not 100% reliable. Here is the output of systemctl status lighttpd.service just before issuing the reload command that triggered the assertion: home ~ # systemctl status lighttpd.service lighttpd.service - Lighttpd Web Server Loaded: loaded (/etc/systemd/system/lighttpd.service) Active: active (running) since Mon, 10 Jan 2011 17:18:44 +0500; 1s ago Process: 2382 (/bin/kill -INT $MAINPID, code=exited, status=1/FAILURE) Process: 2390 (/usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf, code=exited, status=0/SUCCESS) Main PID: 2393 (lighttpd) CGroup: name=systemd:/system/lighttpd.service └ 2393 /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf Here is the backtrace, according to my core file: #0 0x7fe1316b7acb in raise () from /lib/libpthread.so.0 #1 0x00408f6b in crash (sig=6) at src/main.c:118 #2 signal handler called #3 0x7fe130923b25 in raise () from /lib/libc.so.6 #4 0x7fe130925330 in abort () from /lib/libc.so.6 #5 0x00456ff7 in log_assert (file=0x473cb3 src/service.c, line=2184, func=value optimized out, format=value optimized out) at src/log.c:492 #6 0x004206f0 in service_run_next_main (u=0x2721990, pid=2393, code=1, status=0) at src/service.c:2184 #7 service_sigchld_event (u=0x2721990, pid=2393, code=1, status=0) at src/service.c:2525 #8 0x0040c1af in manager_dispatch_sigchld (m=0x25bb1c0) at src/manager.c:2011 #9 0x004117e3 in manager_process_signal_fd (m=0x25bb1c0) at src/manager.c:2186 #10 process_event (m=0x25bb1c0) at src/manager.c:2211 #11 manager_loop (m=0x25bb1c0) at src/manager.c:2345 #12 0x0040a1e5 in main (argc=value optimized out, argv=value optimized out) at src/main.c:1166 -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] service: Allow mainpid to restart in other than SERVICE_EXEC_START.
10.01.2011 18:57, Mirco Tischler wrote:
This patch should fix it. Can you test it? The problem was that after a
the mainpid exits,
and because there are commands left to execute systemd assumes it
executes an ExecStart
line from a type=oneshot service file. But in this case it executes an
ExecReload line.
This patch simply removes the assumptions. AFAICT this should work.
This doesn't crash, but doesn't solve the /bin/kill from ExecStop
sometimes fails problem.
Mirco
---
src/service.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/src/service.c b/src/service.c
index a28eb8a..4ff9f5d 100644
--- a/src/service.c
+++ b/src/service.c
@@ -2181,9 +2181,6 @@ static void service_run_next_main(Service *s, bool
success) {
if (!success)
s-failure = true;
-assert(s-control_command_id == SERVICE_EXEC_START);
-assert(s-type == SERVICE_ONESHOT);
-
s-control_command = s-control_command-command_next;
service_unwatch_main_pid(s);
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] service: Allow mainpid to restart in other than SERVICE_EXEC_START.
10.01.2011 18:57, Mirco Tischler wrote: This patch should fix it. Can you test it? The problem was that after a the mainpid exits, and because there are commands left to execute systemd assumes it executes an ExecStart line from a type=oneshot service file. But in this case it executes an ExecReload line. This patch simply removes the assumptions. AFAICT this should work. On the second thought, I am not sure that I fully agree with the patch. On IRC, we agreed that it is invalid to try to change the main PID from within the ExecReload line. As far as I understand the comment above, the assertion hits if there are more commands to execute after the main PID exits. This can happen legitimately (without invalid service files) due to bad timing: a buggy service was crashed by an external hacker at the same time when the admin attempted to apply the new configuration. So it is indeed wrong to fail the assertion due to it, as it would be a security hole. However, in my opinion, it is also suboptimal (and maybe even wrong) to continue executing new commands when it is clear that the main PID no longer exists although it should - i.e., the service died. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] lighttp unit - graceful reload of configfiles by sending signal to $MAINPID
10.01.2011 22:49, Marius Tolzmann wrote: hi.. [Unit] Description=Lighttpd Web Server After=network.target [Service] Type=forking EnvironmentFile=/etc/conf.d/lighttpd PIDFile=/var/run/lighttpd.pid ExecStartPre=/usr/sbin/lighttpd -t -f /etc/lighttpd/lighttpd.conf ExecStart=/usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf ExecStop=/bin/kill -INT $MAINPID ExecReload=/usr/sbin/lighttpd -t -f /etc/lighttpd/lighttpd.conf ExecReload=/bin/kill -INT $MAINPID ExecReload=/bin/sleep 1 ExecReload=/usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf StandardOutput=syslog StandardError=syslog i still try to get behind all the systemd magic so i have some questions on this unit: can the initial problem of restarting the lighttpd gracefully be solved by something like this?: [Unit] .. ConditionPathExists=/etc/lighttpd/lighttpd.conf [Service] ExecStartPre=/usr/sbin/lighttpd -t ... ExecStart=/usr/sbin/lighttpd ... ExecStop=/bin/kill -INT $MAINPID ExecReload=/usr/sbin/lighttpd -t ... ExecReload=/bin/kill -INT $MAINPID StandardOutput=syslog Restart=on-success ( or on-abort or always .. don't know what the exit-status after graceful kill is in lighty) No, the Restart logic in systemd is not right for lighttpd (or rather: the logic required by lighttpd is insane). Systemd will start a new instance of lighttpd as soon as the main PID (i.e., in the default setup with server.max-worker = 1, the only PID) of the old instance exits, which is too late. I want the old and the new instances of lighttpd to coexist for some time. See: after SIGINT, the old instance does not listen on port 80, but continues servicing large downloads that are still in progress. The new instance accepts new connections and handles them. The old instance will exit as soon as all old transfers ard completed. and why do you explicitly not use the -D option and let systemd do all the forking stuff for you..? you could get rid off the Type= PIDFile= lines.. This would indeed work if I didn't need the funky graceful restart logic. i also removed StandardError=syslog which seems to be redundant here.. OK. If you want to see what went into Gentoo systemd overlay, look here: http://git.overlays.gentoo.org/gitweb/?p=user/systemd.git;a=commitdiff;h=d34961cf8be3743013d026c21ca64078ad0f1255 . Essentially, I gave up, but documented the effort. SignalStop=SIGINT and SignalReload=SIGINT or something similar may be a nice shortcut for doing those kind of things.. Since SignalReload=SIGHUP seems to be a way how it is done most of the time? Yes, this would be a good shortcut. Another question: Doesn't the default KillMode=control-group would send a SIGTERM to the remaining processes of this service immediately after the ExecStop= returns and so break the idea behind a graceful shutdown where the main-process exits and all running http-requests will be finished? (Or is there also a delay of TimeoutSec= between ExecStop= and the first SIGTERM?) The documentation (man systemd.service, search for TimeoutSec) says it waits. Anyway, lighttpd is very easy to set up, the default config works fine for static files, and the only possible trouble is avoided by commenting out the server.use-ipv6 = enable line, so you may want to play with it yourself. To experiment with graceful restarts, you can put some music in the document root and attempt to download it with wget -O /dev/null --limit-rate=20k http://127.0.0.1/file.mp3 while restarting lighttpd. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
