Re: [systemd-devel] mount unit with special requirements
Hi, [...] >> No, I wrote: >> >> *- The partition has to be mounted on boot.* >Well, what does that mean? Do you just want the path to be available? >if so, that's what an automount unit will do for you without actually >mounting the superblock. Or do you want the superblock to be hooked in >already? If so, why? Why wouldn't the automount be good enough? to be honest, I never tried it, but I will - following your approach from the other mail. >> - It has to be unmounted before the nightly copy job, so that an fsck >> can be performed. >Well, but why would you do that. Why isn't it enough to run the fsck >once before the first mount after each time the device initially >appeared? I simply never used automount units, so I had no idea about their capabilities. >Lennart Bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] mount unit with special requirements
Hi, >On Sa, 08.09.18 19:10, Michael Hirmke (m...@mike.franken.de) wrote: [...] >> For the backup "master" I have the following requirements: >> >> - The partition has to be mounted on boot. >> - It has to be unmounted before the nightly copy job, so that an fsck >> can be performed. >> - After that it has to be mounted read only, so that during the copy >> job no other machine can write to it. >> - After finishing the copy job, the partition has to be remounted read >> write again. >I am not sure I fully grok the requirements here, but I'd probably >turn this around, and make the mount an .automount unit with a short >TimeoutIdleSec=, so that the partition is available always under its >file system path, but mounted only on access, and so that fsck is >pulled in by the first access, but not repeated after that (except >when the disk appears). >You could then plug a service between the .autmount unit and the >.mount unit that only has ExecStop= and does the rsync operation. This >way you run rsync right after each access, automatically, and you know >the mount is currently not in effect. this seems to be a really interesting approach. Thx for it. This is exactly the kind of advice, I had hoped for :) I'm going on vacation tomorrow, so I can't test it for now. But after returning, I definitely will try that. Probably I'll have a few more question then ;) >Lennart Thx again. Bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] mount unit with special requirements
Hi, >On Mon, 2018-09-10 at 09:55 +0200, Michael Hirmke wrote: >> >>>> >>>>> (I would just use `umount /var/backup`, however.) >>>> >>>> Can't do that as long as the mount unit is under systemd control. >>>> A few seconds later systemd remounts it on its own. >>>> >>> "noauto" mount option? >> >> This would prevent it from being mounted at startup, which is >> necessary. >If you leave out "noauto", you're telling systemd to mount the file >system when it's ready. You said you didn't want that. From your >problem description, I'd infer that this file system needs to be >mounted only at certain times (while the backup is running). My No, I wrote: *- The partition has to be mounted on boot.* - It has to be unmounted before the nightly copy job, so that an fsck can be performed. - After that it has to be mounted read only, so that during the copy job no other machine can write to it. - After finishing the copy job, the partition has to be remounted read write again. It has to be mounted at boot, because other machines (mainly Windows Server Backup) are writing their backups to it. >suggestion would be to create a dedicated script (or systemd service, >for that matter) that would mount the file system, start the backup, >and unmount / freeze the file system when the backup is done. Yes, I can do that - and in fact I already did. But I want to optimize it and I want to understand systemd, so I thought there could be better approaches. >Regards, >Martin Thx and bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] mount unit with special requirements
Hi, [...] >>> Isn't that commonly done using LVM? If it were on a logical volume, >>> you >>> could fsfreeze /var/backup (to suspend writes during snapshotting), >>> make a >>> LVM snapshot, thaw, mount the read-only snapshot elsewhere and >>> rsync off it. >> >> I never used LVM and this system does not use an LVM partitioning. >fsfreeze should work without LVM. Of course you shouldn't be writing >tons of data to the file system while it's frozen, therefore LVM >snapshot + quick unfreeze would be more robust. I'll have a look, perhaps it really can be useful in this scenario. >> >>> (I would just use `umount /var/backup`, however.) >> >> Can't do that as long as the mount unit is under systemd control. >> A few seconds later systemd remounts it on its own. >> >"noauto" mount option? This would prevent it from being mounted at startup, which is necessary. >Martin Thx and bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] mount unit with special requirements
Hi *, [...] >> - The partition has to be mounted on boot. >> - It has to be unmounted before the nightly copy job, so that an fsck >> can be performed. >> - After that it has to be mounted read only, so that during the copy >> job no other machine can write to it. >> - After finishing the copy job, the partition has to be remounted read >> write again. >> >Isn't that commonly done using LVM? If it were on a logical volume, you >could fsfreeze /var/backup (to suspend writes during snapshotting), make a >LVM snapshot, thaw, mount the read-only snapshot elsewhere and rsync off it. I never used LVM and this system does not use an LVM partitioning. [...] >> jobs fails with messages like "Specified filename /dev/sdf1 has no >> mountpoint." when *stopping* var-backup.mount. >> >Can you be more specific about the messages you get? The closest I found to >yours was "Specified filename * is not a mountpoint" from the `fuser` >command ? which is not called by systemd nor umount as far as I could grep. "Specified filename /dev/sdf1 has no mountpoint." is *exactly* what I get when calling "systemctl stop var-backup.mount" - but only occasionally as I wrote. >(I would just use `umount /var/backup`, however.) Can't do that as long as the mount unit is under systemd control. A few seconds later systemd remounts it on its own. Bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] mount unit with special requirements
Hi *, for my backups I use disks in a way similar to tapes. I have a fixed backup disk with one single partition, which is used for backing up the machine hosting this disk and a few other machines from remote. At night the contents from this disk get copied via rsync to a removable disk of the same size, which is replaced by another one next morning. For the backup "master" I have the following requirements: - The partition has to be mounted on boot. - It has to be unmounted before the nightly copy job, so that an fsck can be performed. - After that it has to be mounted read only, so that during the copy job no other machine can write to it. - After finishing the copy job, the partition has to be remounted read write again. To achive that, at the moment my backup routine calls the following commands: - systemctl mask var-backup.mount - systemctl stop nfsserver smb (to avoid the partition being busy) - systemctl stop var-backup.mount - systemctl start nfsserver smb - fsck -yf /dev/sdf1 - mount -o ro /dev/sdf1 /var/backup - (mount dup partition, fsck dup partition, rsync, umount dup partition) - mount -o remount,rw /dev/sdf1 /var/backup - systemctl unmask var-backup.mount It seems to be unnecessary complicated, but I didn't find a way to achive what I described above with a less complicated approach. Everything else I tried, led to problems with systemd, that tried to take unwanted actions. Even using the commands above, 1 out of 10 jobs fails with messages like "Specified filename /dev/sdf1 has no mountpoint." when *stopping* var-backup.mount. I suspect, though, there is a less complicated and perhaps even more stable approach. Can anyone lead me on the right way? TIA. Bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd core dump
Hi Zbigniew, >On Sun, Oct 08, 2017 at 11:22:00AM +0200, Michael Hirmke wrote: >> Hi, >> >> today systemd crashed on my main server: >> >> Okt 08 10:06:28 perth systemd[1]: Code should not be reached 'Uh, main >> process died at wrong time.' at src/core/service. >> c:2701, function service_sigchld_event(). Aborting. >> Okt 08 10:06:28 perth systemd[1]: Caught , dumped core as pid >> 31706. >> Okt 08 10:06:28 perth systemd[1]: Freezing execution. >> Okt 08 10:06:28 perth systemd-coredump[31707]: Process 31706 (systemd) >> of user 0 dumped core. >> >> This is a machine running openSuSE Leap 42.3, i.e. >> systemd-228-35.1.x86_64. >> >> What information can I provide in what way to help resolving this >> problem? >> Or is this already fixed in a later version of systemd? >Upstream is at v235. So the answer is "yes probably", but this issue >should be reported to suse leap maintainers. I already opened a bug report on openSuSE's bugzilla. >Zbyszek Thx for your answer. Bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd core dump
Hi, today systemd crashed on my main server: Okt 08 10:06:28 perth systemd[1]: Code should not be reached 'Uh, main process died at wrong time.' at src/core/service. c:2701, function service_sigchld_event(). Aborting. Okt 08 10:06:28 perth systemd[1]: Caught , dumped core as pid 31706. Okt 08 10:06:28 perth systemd[1]: Freezing execution. Okt 08 10:06:28 perth systemd-coredump[31707]: Process 31706 (systemd) of user 0 dumped core. This is a machine running openSuSE Leap 42.3, i.e. systemd-228-35.1.x86_64. What information can I provide in what way to help resolving this problem? Or is this already fixed in a later version of systemd? TIA. Bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] suspend hook as user service
Hi Simon, >On Fri, 17 Feb 2017 at 19:41:00 +0100, Michael Hirmke wrote: >> A much better approach is to write a script or program listening for the >> according signals "PrepareForSleep" and "PrepareForShutdown" on the dbus >> interface "org.freedesktop.login1". >This is the thing to do. It allows your program to delay suspend until >it is ready for suspend to happen, or prevent suspend altogether. not really "until it is ready", but for a maximum of 5 seconds ;) >For instance, Telepathy delays suspend so it can try to take instant >messaging connections offline first: >https://cgit.freedesktop.org/telepathy/telepathy-mission-control/tree/src/con >nectivity-monitor.c >S Bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] suspend hook as user service
Hi, >Hi Michael, >thank you for feedback, but you described *system* service and this is the >way I solved my issue for now. The original message was about *user* service >? the service that you can put at $HOME/.config/systemd/user and activate >with: uhm, I understood that you just wanted to have something executed in the context of a given user. And for this purpose the solution I described works in most cases. >systemctl --user enable myservice.service Never tried that, because in the first implementations it didn't work reliably. But what about my second suggestion regarding a script listening to the loginmanager signals? If you are familiar with perl, I could give you my script to adapt it as you need. >R.H. Bye. Michael. >On Fri, Feb 17, 2017 at 07:41:00PM +0100, Michael Hirmke wrote: >> Hi, >> >>>Hi, >> >>>is there any way to start user service before/after suspend.target? In >>>wiki.archlinux.org there are only system sleep hooks [1]. I tried to lock >>>the >> >> yes, but they also describe, how you can add a system service handling >> special user things. >> >> [...] >> >> You can create a service named for example "suspend_user@.service": >> >> < snip snip snip >- >> [Unit] >> Description=User suspend actions for KDE >> After=sleep.target remote-fs.target >> Requires=remote-fs.target >> StopWhenUnneeded=yes >> >> [Service] >> User=%I >> Type=oneshot >> ExecStart=... >> TimeoutSec=300 >> >> [Install] >> WantedBy=sleep.target >> < snip snip snip >- >> >> And enable it with: >> systemctl enable suspend_user@.service. >> >> It worked for me for a while. >> >> A much better approach is to write a script or program listening for the >> according signals "PrepareForSleep" and "PrepareForShutdown" on the dbus >> interface "org.freedesktop.login1". >> You can start it for example in your .bashrc or in the KDE startup >> routines. >> >> >>>R.H. >> >> Bye. >> Michael. >> -- >> Michael Hirmke >> ___ >> systemd-devel mailing list >> systemd-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-timesyncd: Cannot resolve user name systemd-timesync: No such process
Hi Markus, >On Friday 11 November 2016 15:13:00 Michael Hirmke wrote: >> Does anyone know, what "+::" in /etc/passwd means? >This line is for the NIS client. thx for the explanation. >regards >Markur Köberl Bye. Bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-timesyncd: Cannot resolve user name systemd-timesync: No such process
Hi Simon, >On Fri, 11 Nov 2016 at 15:13:00 +0100, Michael Hirmke wrote: >> Does anyone know, what "+::" in /etc/passwd means? >It's to do with the NSS "compat" plugin, which glues together >NIS and a traditional password file. >Look for "Compatibility mode (compat)" in >http://man7.org/linux/man-pages/man5/nsswitch.conf.5.html thx. There seems to be a bug somewhere, I suppose. Either entries behind that line shouldn't be ignored or all entries have to be written before that line. Ok, but that has nothing to do with systemd ;) >S Bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-timesyncd: Cannot resolve user name systemd-timesync: No such process
Hi Lennart, >On Fri, 11.11.16 14:41, Michael Hirmke (m...@mike.franken.de) wrote: >> Hi *, >> >> can anyone help me with this error message: >> >> systemd-timesyncd[857]: Cannot resolve user name systemd-timesync: No >> such process >> >> This happens with systemd-228-13.1.x86_64 on openSuSE Leap 42.2 RC2. >> >> The user account systemd-timesync exists in /etc/passwd. >What does "getent passwd systemd-timesync" and "getent group >systemd-timesync" report? getent passwd systemd-timesync -> returns nothing getent group systemd-timesync -> returns: systemd-timesync:x:463: I found an entry "+::" in my passwd - no idea, what that means. I've never seen that. All entries after that one are reported as non existent by getent. I moved this line to the end of the file, and getent reports the entries missing before. Thx for that hint. Does anyone know, what "+::" in /etc/passwd means? >Lennart Bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-timesyncd: Cannot resolve user name systemd-timesync: No such process
Hi *, can anyone help me with this error message: systemd-timesyncd[857]: Cannot resolve user name systemd-timesync: No such process This happens with systemd-228-13.1.x86_64 on openSuSE Leap 42.2 RC2. The user account systemd-timesync exists in /etc/passwd. timedatectl output: Local time: Fr 2016-11-11 14:40:58 CET Universal time: Fr 2016-11-11 13:40:58 UTC RTC time: Fr 2016-11-11 13:40:58 Time zone: Europe/Berlin (CET, +0100) Network time on: yes NTP synchronized: no RTC in local TZ: no Thx and bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd 210 - mount/umount/remount
Hi Lennart, >On Fri, 14.10.16 12:06, Michael Hirmke (camp...@mike.franken.de) wrote: >> 1. How can I prevent systemd from mounting a manually unmounted >>partition? The partiton should be mounted automatically during system >>start, though. >There were some changes related to this in more recent versions of >systemd. Consider upgrading, 210 is pretty ancient. the distribution I use is openSuSE Leap 42.1 which comes with this version of systemd. Installing a newer version would break a lot of things so I tried to avoid this. But Leap 42.2 is on its way and it contains a much newer version of systemd. So I hope they get it finished soon. >That said, if you don't want systemd to mount the thing, consider >removing it from /etc/fstab (or setting "noauto" on the entry there) >and issuing "systemctl daemon-reload". This would mean, that it isn't mounted on system start, which is necessary for this machine. >In never systemd versions you can also take BSD file lock on the >top-level device node in order to block udev from refreshing the >device and generating events for it. That sounds interesting, but I never heard of this feature. Where can I get more information about it? >> 2. If I would switch from mount/umount to pure systemd behaviour for >>mounting and unmounting partitons in my script, would a command like >>"systemctl stop|start /var/backup" be sufficient? >>And how would a remount command (for read only or read write) look >>like? >"systemctl stop /var/backup" is probably not going to suffice. If you >modify your partition table/disk image during runtime this means the >device will vanish from and return to systemd's view as the accesses >are serialized. Whenever the device pops up again systemd might >requeue the jobs declared in /etc/fstab via the "auto" mount option. I tried it and it behaved exactly as you described above. Therefore it was not useful for my purpose. I then added a mask command before my umount and an unmask command after remounting the partition. Dirty, but working solution. >Lennart Thx and bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd 210 - mount/umount/remount
Hi Karel, >On Fri, Oct 14, 2016 at 12:06:00PM +0200, Michael Hirmke wrote: >> Hi *, >> >> I've read the man pages and some more documentation about the mount >> behaviour of systemd, but I couldn't find a definitive answer to my >> questions. >> I have a backup script, that copies all files to backup to a hard disk >> partition, then duplicates the partition to one on a second disk, which >> in turn is changed every day. Before duplicating, the script tries to >> umount the partition on the original disk, does an fsck and then mounts >> the partition read only. When duplicating is finished, the original >> partition is remounted read write again. >Not sure if you copy individual files or all partition (dd(1) or so), >but would be enough to use fsfreeze(8) to avoid umount/mount? I copy individual files with rsync. Therefore I want to make sure, the original partition is clean. >I guess you can call fsck on duplicated partition on the second disk. No, because when copying individual files I never can be sure, that everything goes right. >IMHO fsfreeze is less invasive than umount. Or use LVM snapshots ;-) I know :) But that is not what I need. >Karel Thx and bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd 210 - mount/umount/remount
Hi again, [...] >nfsserver and postfix are depending on local-fs.target, which includes >var-backup.mount. >When stopping /var/backup with systemctl, systemd also stops nfsserver >and postfix. Therefore this is not a solution, because in fact both >don't need /var/backup. >How can I solve this? it seems to be a very ugly solution, but masking var-backup.mount before umounting it and unmasking it after remounting works. Hopefully there are no side effects. Does anyone know any not so ugly solution? >[...] Bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd 210 - mount/umount/remount
Hi, [...] >>systemd shouldn't generally start any unit on a whim ? if the corresponding >>.mount was started, then it likely was either by request, or as a >>dependency of some program, or via autofs (if you use systemd.automount). >I don't use systemd.automount. >No one requested it as far as I can see. >And "systemctl list-dependencies var-backup.mount" only shows >var-backup.mount. found it out: nfsserver and postfix are depending on local-fs.target, which includes var-backup.mount. When stopping /var/backup with systemctl, systemd also stops nfsserver and postfix. Therefore this is not a solution, because in fact both don't need /var/backup. How can I solve this? [...] Bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd 210 - mount/umount/remount
Hi Michael, >On Fri, 14 Oct 2016, Mantas Mikul?nas wrote: >[...] >>>And how would a remount command (for read only or read write) look >>>like? >>> >> >> There isn't any. Use `mount`. >FWIW, I'm pretty sure "systemctl reload var-backup.mount" will remount the >filesystem. yes, but not changing from read only to read write and back. >You probably want to avoid "restart" though. :-p >- Michael Bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd 210 - mount/umount/remount
Hi Mantas, thx for your answer. [...] >> 1. How can I prevent systemd from mounting a manually unmounted >>partition? The partiton should be mounted automatically during system >>start, though. >> >First, see if you can figure out *why* systemd mounted it. I tried to found that out, but couldn't find any reason. >systemd shouldn't generally start any unit on a whim ? if the corresponding >.mount was started, then it likely was either by request, or as a >dependency of some program, or via autofs (if you use systemd.automount). I don't use systemd.automount. No one requested it as far as I can see. And "systemctl list-dependencies var-backup.mount" only shows var-backup.mount. >> 2. If I would switch from mount/umount to pure systemd behaviour for >>mounting and unmounting partitons in my script, would a command like >>"systemctl stop|start /var/backup" be sufficient? >> >Looks about right, though in some cases `systemctl foo var-backup.mount` >might be needed. Ok, thx. >But, I don't think it will make any difference. >>And how would a remount command (for read only or read write) look >>like? >> >There isn't any. Use `mount`. Ok. Bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd 210 - mount/umount/remount
Hi *, I've read the man pages and some more documentation about the mount behaviour of systemd, but I couldn't find a definitive answer to my questions. I have a backup script, that copies all files to backup to a hard disk partition, then duplicates the partition to one on a second disk, which in turn is changed every day. Before duplicating, the script tries to umount the partition on the original disk, does an fsck and then mounts the partition read only. When duplicating is finished, the original partition is remounted read write again. The script uses the "ancient" mount and umount commands, but once in a while, systemd takes over and remounts the disk, before fsck has been finished. So my questions are: 1. How can I prevent systemd from mounting a manually unmounted partition? The partiton should be mounted automatically during system start, though. 2. If I would switch from mount/umount to pure systemd behaviour for mounting and unmounting partitons in my script, would a command like "systemctl stop|start /var/backup" be sufficient? And how would a remount command (for read only or read write) look like? TIA. Bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] does "Before=network.target" really work
Hi Xin, >Hi, >I have a service, and want it to be stopped only after network is >stopped when system shutdown. >I checked "man systemd.special ", network is a special internal >service for systemd, , and I found "network.target": >"at shutdown, a unit that is ordered after network.target will be >stopped before the network -- to whatever level it might be set up >then -- is shut down". >That means "After=network.target" can work well. >But my situation is opposite to that, I need "a unit that is ordered >before network.target will be stopped *after* the network so >shutdown". >So I added "Before=network.target" to .service file. can it really >work as I expect? it depends on what you're trying to do with this information. AFAIK network.target is related to the network stack as such. It does not apply to a certain interface is up, down, activated or deactivated. If you need the information for the network stack being up or down, the use of network.target is ok - and works for me. >Thanks Bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Perl Net::DBus, org.freedesktop.system1 and inhibitor locks
Hi Lennart, >On Wed, 25.05.16 18:13, Michael Hirmke (m...@mike.franken.de) wrote: [...] >> Sorry, I forgot to add information regarding my environment. >> I use openSuSE Leap 42.1 with a Plasma 5 desktop. >I don't know if KDE respects these advisory locks and shows them in >the UI, or does not. Please ask the KDE people regarding this. ok, will do that. Thx a lot. >Lennart Bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Perl Net::DBus, org.freedesktop.system1 and inhibitor locks
Hi Mantas, >In other words, mixing up OS file descriptors and Perl file handles? exactly 8-< >D-Bus can only send and receive raw FDs; Net::DBus doesn't know what kind >of handle it's supposed to be, so you need to either create one manually, >or just work with the FD directly (I think the relevant function is >sysclose()?...) For the moment I create a handle manually and also open it manually. Bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Perl Net::DBus, org.freedesktop.system1 and inhibitor locks
Hi again, [...] >>> - I am not able to close the file descriptor in the pre block of the >>> signal handler. Whenever I try, I get an error, that the descriptor >>> is closed. >>This suggests something else closed the fd for you? >Yes, but who or what might that be? >As I wrote above - at the moment I'm the only one using the system and I >have no idea, what component might fiddle with my file descriptors. >Do you have any hint, how I could find that out / debug it? >And there is the fact, that the lock is still in the list of inhibitors. >As far as I understand the docs, the entry should be gone when the fd is >closed. forget about that question - I have never asked it 8-(( It was a really stupid error in my perl code - the file descriptor was never open. I got a file handle, but didn't realize that I have to open it myself. Now it works as expected. >>Lennart Bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Perl Net::DBus, org.freedesktop.system1 and inhibitor locks
Hi Lennart, thx for your answer! [...] >Being just advisory means that a user can shut down the system even if >a lock is taken, however, the lock is tracked and the expectation is >that the DE of your choice will still show them first, and ask for >confirmation to ignore them before you actually use your powers to >override them. GNOME does this, but I am not sure if your DE does it. Sorry, I forgot to add information regarding my environment. I use openSuSE Leap 42.1 with a Plasma 5 desktop. And at the moment my tests are restricted to run my script and then send the system to sleep myself - so no other user is involved for the moment. >"systemctl poweroff" will show these locks in a similar way too, but >not for the root user. >> - I am not able to close the file descriptor in the pre block of the >> signal handler. Whenever I try, I get an error, that the descriptor >> is closed. >This suggests something else closed the fd for you? Yes, but who or what might that be? As I wrote above - at the moment I'm the only one using the system and I have no idea, what component might fiddle with my file descriptors. Do you have any hint, how I could find that out / debug it? And there is the fact, that the lock is still in the list of inhibitors. As far as I understand the docs, the entry should be gone when the fd is closed. >Lennart Bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
