Re: [systemd-devel] Weird udev issue: char device replaced by regular file on suspend
On Thu, 25 Jun 2015 22:07:27 +0200 Johannes Bauer dfnsonfsdu...@gmx.de wrote: Oh, okay, this would be insanely weird then if it were a kernel bug. Do you think LKML is the right place to post this to then? No, I think the suspend-to-RAM scripts should be checked or asked on the mailing list of the upstream project. P.S. I didn't say is the kernel to blame, just said that udev is not involved in creating device nodes anymore and because of this is more likely whatever scripts are running to do the suspend-to-RAM and not udev or the kernel. -- Robert Milasan L3 Support Engineer SUSE Linux (http://www.suse.com) email: rmila...@suse.com GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] howto handle one time shutdown programs
В Thu, 25 Jun 2015 11:09:22 -0700 Johannes Ernst johannes.er...@gmail.com пишет: Hallo Andreas, On Jun 25, 2015, at 7:57, Andreas Buschmann busch...@tech.net.de wrote: Hello, I am writing a systemd .service file to handle NVDIMMs. - start - stop - reload all work The problem child is restart. Restart is internally implemented as stop followed by start. The problem is, that stop calls a program which does something to the NVDIMM hardware. After that no further access to the NVDIMMs is possible before the next reboot of the server. How should I handle that sort of logic with systemd? How is that different from the user executing: systemctl start your.service systemctl stop your.service systemctl start your.service without reboot? Those initscripts I am aware of avoided this issue by not stopping anything on restart. This made it possible to do service foo restart without losing its state. Converting such services to systemd unit breaks things. Such restarts happen without user explicit intervention e.g. during package updates. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SysVInit service migration to systemd
Lesley Kimmel píše v Pá 26. 06. 2015 v 08:15 -0500: Hi all; I've been working with RHEL5/6 for the past several years and have developed many init scripts/services which generally use lock files and PID files to allow for tracking of the service status. We are moving to RHEL7 (systemd) in the near future and I am looking for instruction or tutorials on how to effectively migrate these scripts to work with systemd. http://0pointer.de/blog/projects/systemd-for-admins-3.html I found https://wiki.archlinux.org/index.php/Systemd#Service_types which seems somewhat promising but it is fairly high-level. It looks like I may be able to use the 'forking' type with the 'pidfile' parameter to somewhat mimic what the scripts to today. However, I have a couple of questions: -How does systemd track whether it should be stopping a service at shutdown (analogous to the /var/lock/subsys files in SysVInit)? Systemd tracks the services using cgroups, so it knows that the service is running and needs to be stopped. -Are there merits to using the notify or dbus types? If so does anyone know of a tutorial I could use to get to that point? (FYI, I'm not a developer but I learn complicated things quickly). -If the current service logs to a custom, dedicated log is there a way to get systemd to provide the same type of output that it does for the built-in system services or must I make some modifications to integrate with journald? Look at the Administrators Blog Series and Developers Series https://wiki.freedesktop.org/www/Software/systemd/ Thanks ahead of time, Lesley Kimmel, RHCE Linux/Unix Systems Engineer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel Regards Lukas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SysVInit service migration to systemd
В Fri, 26 Jun 2015 10:02:41 -0500 Lesley Kimmel ljkimme...@hotmail.com пишет: Thanks for the information. I've seen that blog before. Unfortunately, it only describes a starting a service that already has a good level of integration with some of the underlying infrastructure of systemd (e.g. dbus). Let me be a little more specific about what I'm trying to accomplish and see if anyone has any thoughts on how systemd could help (or impede me). I have a collection of servers hosting many processes such as Apache HTTPD, a database, and Java application servers. Using init these servers would: a) need to be started in a specific order and b) take a long time to start. To improve both of these scenarios I created a Python service which took an XML configuration file describing the dependencies of the various components. The Python service is started by init and forks so as to not stop the boot process. The forked process then does some basic dependency checking (including remote tests, mostly telnet or pings) before starting local services using init scripts that are not configured to be started by init. That sounds exactly like what pacemaker does. I'm wondering, with systemd, if this Python control daemon would be required at all. Does systemd have the ability to check the status of remote servers? No. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SysVInit service migration to systemd
On Fri, Jun 26, 2015 at 4:15 PM, Lesley Kimmel ljkimme...@hotmail.com wrote: Hi all; I've been working with RHEL5/6 for the past several years and have developed many init scripts/services which generally use lock files and PID files to allow for tracking of the service status. We are moving to RHEL7 (systemd) in the near future and I am looking for instruction or tutorials on how to effectively migrate these scripts to work with systemd. I found https://wiki.archlinux.org/index.php/Systemd#Service_types which seems somewhat promising but it is fairly high-level. It looks like I may be able to use the 'forking' type with the 'pidfile' parameter to somewhat mimic what the scripts to today. However, I have a couple of questions: Usually systemd detects the main process even without PIDFile, using cgroups to keep track. -How does systemd track whether it should be stopping a service at shutdown (analogous to the /var/lock/subsys files in SysVInit)? All service control requests go through the always-running init process, so it can just keep track of service status internally without having to write it out. [This also means services run in a clean environment and can't ask for interactive input when starting. Upstart and even /etc/inittab also work the same way.] Systemd also monitors whether the service processes are actually running – by putting each into a separate cgroup – so it generally avoids issues such as stale pidfiles. -Are there merits to using the notify or dbus types? If so does anyone know of a tutorial I could use to get to that point? (FYI, I'm not a developer but I learn complicated things quickly). Similar to Type=forking, they both let systemd know whether the service is ready or still initializing (which can't be done with the default Type=simple). Type=dbus might be best for creating DBus-activatable services compatible with regular dbus-daemon, since it has mostly the same expectations as dbus-daemon: the service doesn't fork, and is considered ready as soon as it finally claims the configured BusName. Type=notify is somewhat more lightweight – the service just needs to send READY=1 over a Unix socket. (The service can also show some additional information in `systemctl status` – e.g. lldpd could send STATUS=No neighbors). libsystemd has sd_notify(3) http://www.freedesktop.org/software/systemd/man/sd_notify.html for this, though it could be done using regular socket API. I suppose the same notify socket could be exposed to all other service types. I don't know why it isn't yet. -If the current service logs to a custom, dedicated log is there a way to get systemd to provide the same type of output that it does for the built-in system services or must I make some modifications to integrate with journald? `systemctl status` only reads from the journal. The journal, however, also receives messages sent using the traditional syslog API or written to the kernel log – in addition to its native sd_journal_send(3) http://www.freedesktop.org/software/systemd/man/sd_journal_send.html – so that already covers most services. You could also use rsyslogd to feed messages from custom text logs into the journal, using its omjournal module. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Weird udev issue: char device replaced by regular file on suspend
On 26.06.2015 07:43, Greg KH wrote: It's one byte long and this one byte is exactly the data that my userspace program tried to send. But obviously my user space program could not have created that node (no permission to write in /dev, obviously, and my program has no suid or anything, runs just as UID 1000). Are you sure about the permissions of that script? Dead sure: $ ps axu | grep hifictrl joe 2815 0.0 0.0 16184 968 pts/5S+ 11:04 0:00 grep --colour=auto hifictrl joe 15670 0.0 0.0 37212 8308 ?SJun23 0:43 /usr/bin/python3 ./hifictrl $ pstree -s -p 15670 init(1)───hifictrl(15670) $ ps -alU joe | grep hifi 1 S 1000 15670 1 0 80 0 - 9303 poll_s ?00:00:44 hifictrl No funny business, just my local user opening up the device file once, then the script runs forever and occasionally does a few reads and writes. This really looks like the tty device is not present (suspend disconnects the device which removes the /dev node) and then when you resume, your script runs and writes a byte to /dev/ttyUSB0 before the device node is created. I agree, but this wouldn't explain the user/permissions the /dev/ttyUSB0 node gets when it's created as a regular file. Another thing: Whenever this issue hits, wouldn't the kernel recognize that /dev/ttyUSB0 is already taken and rename the device to /dev/ttyUSB1? Because that's not happening (there is just no char device created at all) Like others have said, this isn't a udev issue as udev isn't involved in creating device nodes. I think you should change your script to test to see if /dev/ttyUSB0 is present _before_ you write to it :) Well the thing is that I do my open once and of course I do check if it's present before I do the open (I need to traverse some udevadm info in order to find out which serial adapter is the correct one in case it isn't /dev/ttyUSB0). Then I should have my fd and I don't think you suggest rechecking if the char dev node exists before doing write(2), right? In case the write(2) fails I wait 30 seconds before rescanning the files, and I only ever do open(2) if the node passed all the udevadm info checks. So I really think that I'm innocent here and if you're saying this can't be a kernel issue then the last one left would be the Python interpreter itself. It performs os.write(fd, data), but this also runs with the permissions of my local user. So, in any case, weird. The only thing I could offer would be to strace the whole process. But since it somehow really seems to be linked with the overall speed of my system, I'm guessing the bug will magically disappear once I strace it :-( Best regards, Johannes ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Weird udev issue: char device replaced by regular file on suspend
No way! You're totally awesome, that was the right track... On 26.06.2015 07:14, Martin Pitt wrote: This sounds like a script or program that runs for suspend tries to apply an atomically update file contents approach (write data into a file.new, then mv file.new file) to a /dev node, which would result in this situation. This is sometimes hidden in some API like g_file_set_contents(). Can you reproduce this with a direct echo mem | sudo tee /sys/power/state ...no. I couldn't reproduce it, tried about twenty times, but everything worked smooth as could be... ? This will circumvent any suspend etc. hooks that you might have: pm-utils, /usr/lib/systemd/system-sleep/ hooks, or something an inhibitor might do. I. e. it could be that NetworkManager sets a suspend inhibitor, tries to stop modemmanager before suspend and restart it after, and that might mis-handle /dev/ttyUSB0. (We didn't get any report about this so far, so I doubt it's actually modemmanager -- it just illustrates how this could happen in principle). ...so I looked into the scripts that execute when suspend is initiated. And I found leftovers of a device driver of some shady EPROM writer which I had installed about a year ago in /etc/pm/sleep.d/. It was a binary, but strings and grep showed that it really had /dev/ttyUSB0 hardcoded somewhere in there. Disabled the thing, problem is gone. Also explains the weird permissions (suspend script runs with root privileges obviously). And that they also use the $ sign to encode some kind of command was apparently just coincidence. Oh man, I'm so sorry for bothering all you guys but at the same time so insanely happy this problem is finally solved. Even though the solution was quite unspectacular. Thank you so very much for your help. All the best, Johannes ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] howto handle one time shutdown programs
Am 26.06.2015 um 09:31 schrieb Andrei Borzenkov: How is that different from the user executing: systemctl start your.service systemctl stop your.service systemctl start your.service without reboot? Those initscripts I am aware of avoided this issue by not stopping anything on restart then it is not a restart and that initscript is broken - period This made it possible to do service foo restart without losing its state. Converting such services to systemd unit breaks things. Such restarts happen without user explicit intervention e.g. during package updates. then file a bugreport at your distribution for the apckage and explain why the rpm-scripts are doing only harm and should at least be removed from package xyz or just rebuild that package without the rpm-scripts at your own, did that for a ton of server packages on Fedora because the lack of a systemwide don#t restart anything until a said so option signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] SysVInit service migration to systemd
Hi all; I've been working with RHEL5/6 for the past several years and have developed many init scripts/services which generally use lock files and PID files to allow for tracking of the service status. We are moving to RHEL7 (systemd) in the near future and I am looking for instruction or tutorials on how to effectively migrate these scripts to work with systemd. I found https://wiki.archlinux.org/index.php/Systemd#Service_types which seems somewhat promising but it is fairly high-level. It looks like I may be able to use the 'forking' type with the 'pidfile' parameter to somewhat mimic what the scripts to today. However, I have a couple of questions: -How does systemd track whether it should be stopping a service at shutdown (analogous to the /var/lock/subsys files in SysVInit)? -Are there merits to using the notify or dbus types? If so does anyone know of a tutorial I could use to get to that point? (FYI, I'm not a developer but I learn complicated things quickly). -If the current service logs to a custom, dedicated log is there a way to get systemd to provide the same type of output that it does for the built-in system services or must I make some modifications to integrate with journald? Thanks ahead of time, Lesley Kimmel, RHCE Linux/Unix Systems Engineer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] howto handle one time shutdown programs
Andreas Buschmann wrote on 25/06/15 15:57: Hello, I am writing a systemd .service file to handle NVDIMMs. - start - stop - reload all work The problem child is restart. Restart is internally implemented as stop followed by start. The problem is, that stop calls a program which does something to the NVDIMM hardware. After that no further access to the NVDIMMs is possible before the next reboot of the server. How should I handle that sort of logic with systemd? You can't. Restart is always a stop and start again. You can, however, implement a reload as you've already done. This is the defined mechanism to tell a given daemon (or subsystem - whatever) to maintain it's state but reload itself. In order to prevent bad things happening when users manually stop your unit, you may want to look into the RefuseManualStop= directive (man systemd.unit) which will prevent your unit being stopped except indirectly via dependencies. Typically this would only be when the user reboots. You would then want to make sure that anything that really does want a stateful reload uses the reload action. HTHs Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Failed to mount a crypted device with 'tmp' option
Hi, I'm setting up an encrypted device at boot using cryptsetup. This device is formatted at each boot (I'm using 'tmp' option in /etc/crypttab). Also this device is mounted at boot time (a corresponding entry in /etc/fstab has been made) and is also fsck'ed (fs_passno=2). However it seems that the mount happens at the same time cryptsetup lib is formatting the disk which causes trouble. Here is part of the boot log: - ... systemd-cryptsetup[230]: Set cipher aes, mode cbc-essiv:sha256, key size 256 bits for device kernel: sha256_ssse3: Using SSSE3 optimized SHA-256 implementation modprobe[309]: FATAL: Error inserting padlock_sha (/lib/modules/3.11.10-29-default/kernel/dr kernel: bio: create slab bio-1 at 1 systemd[1]: Found device /dev/mapper/cr_tmp. systemd[1]: Starting File System Check on /dev/mapper/cr_tmp... mke2fs[318]: mke2fs 1.42.8 (20-Jun-2013) mke2fs[318]: Filesystem label= mke2fs[318]: OS type: Linux mke2fs[318]: Block size=1024 (log=0) mke2fs[318]: Fragment size=1024 (log=0) mke2fs[318]: Stride=0 blocks, Stripe width=0 blocks mke2fs[318]: 25688 inodes, 102400 blocks mke2fs[318]: 5120 blocks (5.00%) reserved for the super user mke2fs[318]: First data block=1 mke2fs[318]: Maximum filesystem blocks=67371008 mke2fs[318]: 13 block groups mke2fs[318]: 8192 blocks per group, 8192 fragments per group mke2fs[318]: 1976 inodes per group mke2fs[318]: Superblock backups stored on blocks: mke2fs[318]: 8193, 24577, 40961, 57345, 73729 mke2fs[318]: [49B blob data] mke2fs[318]: [46B blob data] systemd-fsck[320]: /dev/mapper/cr_tmp is in use. systemd-fsck[320]: e2fsck: Cannot continue, aborting. systemd-fsck[320]: fsck failed with error code 8. systemd-fsck[320]: Ignoring error. systemd[1]: Started File System Check on /dev/mapper/cr_tmp. systemd[1]: Mounting /mnt/cr_tmp... mount[324]: mount: /dev/mapper/cr_tmp is already mounted or /mnt/cr_tmp busy systemd[1]: mnt-cr_tmp.mount mount process exited, code=exited status=32 systemd[1]: Failed to mount /mnt/cr_tmp. systemd[1]: Dependency failed for Local File Systems. systemd[1]: Triggering OnFailure= dependencies of local-fs.target. systemd[1]: Unit mnt-cr_tmp.mount entered failed state. - So my question, is this a known bug or am I doing something wrong ? Thanks. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
