| systemdlete | bareos-fd is a daemon that needs access to the network to operate. It currently fails to start, and I believe it is due to the lack of wireless availability -- a timing problem: It takes a moment for my laptop to get a wireless connection. | 00:37 |
|---|---|---|
| systemdlete | the bareos-fd script header seems to require networking to be up first, but for some reason, the daemon does not seem to reliably fire up every time. | 00:37 |
| systemdlete | I'm wondering if this is because there is some configuration for the hardwired network (even though not used most of the time) while wicd is somewhat disconnected from that configuration. But this is typical of my understanding of the networking options at a high level-- I know that the /etc/network/interfaces and wicd are two different realms and they can stomp on each other. | 00:39 |
| systemdlete | and do frequently | 00:39 |
| systemdlete | I'm looking for a way to delay the daeamon even attempting a start until the wireless is up and connected completely | 00:39 |
| systemdlete | I'd rather not muss with the script itself since I do not maintain it | 00:40 |
| systemdlete | thanks -- this might be simple and straightforward or it might be impossible without submitting a bug to the bareos maintainers | 00:40 |
| systemdlete | Hoping this is just a minor tweak to the sysvinit configuration somewhere | 00:41 |
| gnarface | not sure but maybe try it with the wired ethernet configuration in /etc/network/interfaces commented-out so that there's only wireless | 00:41 |
| gnarface | ... test a few times that way just to test the theory | 00:41 |
| gnarface | maybe if wireless is the only one, or even just the first one, it will behave differently | 00:41 |
| systemdlete | Let me check what is actually there... | 00:41 |
| systemdlete | (yeah, I think you are right) | 00:41 |
| gnarface | if the wifi handshake still happens after it consideres networking to be "up" though maybe tie the script to something even later | 00:42 |
| gnarface | that's a hack but a simple quick one | 00:42 |
| gnarface | i think it might be possible that the wifi router can cause this misbehavior independently of the init, but i'm not 100% sure of that | 00:42 |
| gnarface | it's been a while since i've had to use wireless extensively really | 00:43 |
| gnarface | there could be a problem in there | 00:43 |
| systemdlete | good idea, thanks. Well, as it turns out, I do have an entry for the ethernet port. So I could try commenting it out. | 00:43 |
| systemdlete | besides, I believe wicd has a facility for ONE ethernet connection anyway, so if I need it, I could just configure it there. | 00:44 |
| systemdlete | I rarely use the hard wire. The only time is for doing installations of the OS (e.g., installing beowulf; I created a separate partition for it so that I still have ascii as a "spare" in case the beowulf or other install failed) | 00:45 |
| systemdlete | (I prefer to work that way, based on experience!) | 00:46 |
| systemdlete | gnarface: That worked, at least this time. | 00:47 |
| systemdlete | since I use the wireless mainly on the laptop, I think I'll stay with wicd entirely and avoid configuring anything via the interfaces file. | 00:47 |
| systemdlete | gnarface: Voila! S04wicd but S03bareos-fd... | 01:25 |
| systemdlete | which explains it | 01:25 |
| systemdlete | realistically, it is a backup daemon, so I wonder why they gave it so low a number in the ordering | 01:26 |
| systemdlete | I suppose I could rename the bareos script to have a higher number, like 99 | 01:26 |
| systemdlete | but I wonder if there is a more compliant way? | 01:28 |
| systemdlete | for now I will submit a request to the devs at bareos to change the ordering number for the script -- I doubt anyone will have an issue with that. | 01:29 |
| gnarface | well what is important is you found a way to make it work | 01:33 |
| systemdlete | yeah, but I'm not sure how to go about changing the ordering (names of linked init files) in some kind of conformant fashion | 01:39 |
| systemdlete | brute force will work, of course. But that may spell problems if I do an update which includes changes to the init files | 01:39 |
| gnarface | yes, the truth is you should just tar them all up once you have them set right in case you have to restore them later | 01:41 |
| gnarface | not all postinstall scripts are so badly behaved that they'll munge your changes but lots of them are | 01:42 |
| systemdlete | uhm. couldn't an upgrade to bareos also include changes to those scripts? | 01:42 |
| gnarface | yea, and if they didn't make it smart enough to avoid stuff you'd touched they'd get clobbered | 01:42 |
| rwp | I didn't read the scrollback but bareos shouldn't be picking numbers. Instead they pick dependencies and "insserv" automatically determines numbers and ordering topologically. | 01:42 |
| systemdlete | I would hope there is a way to do this via the rc scripts | 01:42 |
| systemdlete | rwp: That is what I'm talking about | 01:42 |
| gnarface | debian is supposed to be smart enough to not clobber changes to /etc/ but even the openssh package has been known to do it | 01:43 |
| gnarface | openssh-server at least | 01:43 |
| rwp | Right. The "conffile" handling. But that can be clobbered in a postinst script. | 01:43 |
| systemdlete | rwp: so the problem then is that the bareos init script does not have a dep for wicd, only for networking | 01:44 |
| rwp | Speaking of which I highly recommend using "etckeeper" to version /etc with a git repository. Then one can always go back through the history as needed. | 01:44 |
| systemdlete | so the issue is really that bareos needs to be more accommodating for different networking configs, which is unrealistic. No devs will want that headache | 01:44 |
| rwp | So... networking comes up with the loopback device comes online. And then wicd is managing dynamic mobile networking that may change while the system is running. | 01:45 |
| rwp | But bareos does not handle networking changing while it is running? Is that the root of the problem? | 01:45 |
| rwp | (I am only aware that bareos is a backup utility and that's all.) | 01:45 |
| systemdlete | rwp, gnarface: I suppose I could manually modify the init script to depend on wicd. Then all the links should work right | 01:45 |
| systemdlete | not a matter of the network changing. It has a dependency on networking in the header of the script, as expected. | 01:46 |
| rwp | That would be a good initial test regardless. Because then you would know if that solves the problem or not. | 01:46 |
| systemdlete | but it doesn't have one for wicd | 01:46 |
| systemdlete | (right) | 01:46 |
| systemdlete | see? | 01:46 |
| rwp | Also note that /etc/init.d/ is in /etc and those files are all "conffiles" and so on upgrade dpkg will not smash your locally customized files. | 01:47 |
| gnarface | rwp: yea it's just a race condition between $network "up" and whatever assumes wicd is working and connected to a router already by then, which isn't quite happening fast enough all the time | 01:47 |
| rwp | Instead it will ask you at every upgrade what you want to do about it. Which is a PITA and something I _try_ to avoid whenever possible. | 01:47 |
| systemdlete | gnarface: Wicd has its own script | 01:47 |
| systemdlete | rwp: exactly | 01:47 |
| gnarface | systemdlete: hmmm, maybe depending on it directly would not be a bad idea then | 01:47 |
| gnarface | systemdlete: it wouldn't be a change they'd likely adopt upstream though, i think at some level, this stuff needs customization | 01:48 |
| rwp | I am not sure if Bareos is designed to be used in a dynamic network state environment. Is it? If not then really it should be handled differently. | 01:48 |
| systemdlete | btw, I did get the hardwire config to work in wicd. So I don't need to deal with the conflicts between the interfaces file vs wicd config | 01:48 |
| systemdlete | dynamic? | 01:48 |
| systemdlete | You mean as in wireless is dynamic? | 01:49 |
| rwp | Dynamic because isn't that what wicd is used for? Dynamically connecting to networks via a user dialog for selection? | 01:49 |
| systemdlete | yes, true | 01:49 |
| rwp | That's the only way I have ever used wicd. And I have been a user of wicd for a decade or something. | 01:49 |
| systemdlete | you didn't mean dynamic as in switching or comporting with both the "networking" and "wicd" network configs | 01:50 |
| systemdlete | I follow now | 01:50 |
| systemdlete | the reality here is that the laptop is on the wireless almost always | 01:50 |
| rwp | I meant that the network state might be UP or DOWN at different times while other programs and daemons are running. | 01:50 |
| systemdlete | (except for initial OS installs, and the like, where trying to work with wireless can be a viscious circle) | 01:51 |
| rwp | I meant that the default route and the IP address might change while other programs and daemons are running. | 01:51 |
| rwp | Some daemons care about these things. Some do not. | 01:51 |
| systemdlete | the network state, really, should be up at all times. Of course, it may take wicd a moment or so to actually make a connection. The question here is will wicd wait for that event, or will it surrender control back to the scripts driver (i.e., parallel) | 01:52 |
| systemdlete | (for parallel booting) | 01:52 |
| systemdlete | (speed, the thing Mr. L. was so anal about) | 01:52 |
| systemdlete | (and got us to this awful convo) | 01:52 |
| rwp | For example if you "ss -na | grep ^tcp.*LISTEN | less" and look at the daemons running on a system. Some will listen to *:80 and some will listen on the current IP address 192.168.230.119:53 for example. | 01:53 |
| systemdlete | my gut says wicd will relinquish control even before the wireless connnection is established | 01:53 |
| systemdlete | rwp: Trust me, bareos MUST have a network connection to do any good in the world. | 01:54 |
| rwp | For the daemons that listen on *: or [::]: or 0.0.0.0: or other wildcard addresses then the *actual* IP does not matter. | 01:54 |
| rwp | But for some daemons (named is one of them) they bind explicitly to each IP address on each network device explicitly. And then of course when those go UP or DOWN they must react. | 01:54 |
| systemdlete | ok | 01:54 |
| systemdlete | but back to the issue at hand | 01:55 |
| rwp | A program can ioctl() call to ask about the current state and react to changes. I have written software that does it that way and those are okay. | 01:55 |
| rwp | But if bareos doesn't handle it nicely then it will need to be restarted or something whenever the network interface state is changed. | 01:55 |
| systemdlete | I have no idea what bareos does internally, at least not to any detailed extent. | 01:55 |
| rwp | For things that happen in an event driven way and must handle those types of changes there is usually a network event script installed. | 01:56 |
| systemdlete | again, the network needs to be up before bareos runs. otherwise, it will fail to start. and that is what I'm trying to avoid | 01:56 |
| rwp | For example /etc/network/if-up.d/postfix is installed with Postfix to handle network changes that happen while Postfix is running. | 01:56 |
| systemdlete | network will need to be up and always up. period. | 01:56 |
| rwp | Then... Why use wicd? That seems the wrong tool for it then. | 01:57 |
| systemdlete | There is no need for any special handling like that... here in my house. In a big data center, maybe. | 01:57 |
| systemdlete | because wicd is convenient. It handles all the wireless config and so forth. | 01:57 |
| rwp | I would simply use wpa_supplicant then and just connect using ifupdown always. | 01:57 |
| systemdlete | hmmmm. that's a thought. | 01:58 |
| rwp | It's certainly okay to use wicd. But then that decides on a dynamic event driven path. Which means like what Postfix did. | 01:58 |
| systemdlete | you know what? I think this has taken up too much space and time. I will see if I can get help in the bareos channels. With the substantial base of users, bareos should be doing whatever it needs to (postfix style maybe) not ME | 01:59 |
| systemdlete | or YOU | 01:59 |
| systemdlete | lol | 01:59 |
| systemdlete | also, I am about 3 major releases behind on bareos. I've had difficulty upgrading in the past, but maybe now with beowulf it will make it smoother. (Iirc, there were some lib deps issues) | 02:00 |
| systemdlete | the laptop has beowulf | 02:01 |
| systemdlete | but the host side is still running ascii | 02:01 |
| systemdlete | because that is on my list of to-dos... | 02:01 |
| systemdlete | and I've been attending other stuff lately | 02:01 |
| rwp | Another completely independent path is to use a separate supervisor monitor (such as "monit" or something) to check on system status and to start or stop bareos as needed/desired. | 02:02 |
| systemdlete | the laptop daemon has to be connected and running all the time. Not that it is doing much most of the day and night, but when the host system calls up to run backups, it had better be up and listening good! | 02:03 |
| systemdlete | And that is just the architecture of bareos. Don't shoot me. | 02:03 |
| systemdlete | maybe the newest version of bareos has a mechanism similar to postfix et al | 02:04 |
| systemdlete | (that would be nice) | 02:05 |
| systemdlete | again, I don't know. maybe it already does have it but it doesn't always work yada yada | 02:05 |
| systemdlete | who knowss | 02:05 |
| systemdlete | I have not examined their source code too closely, tbh | 02:05 |
| systemdlete | thanks gnarface and rwp. I'll give monit a looksee and determine if that could help, if simple to do. | 02:06 |
| systemdlete | maybe I just need a cron job to check the status of the daemon every hour or so. | 02:06 |
| rwp | I favor the way Postfix did things with a /etc/network/if-up.d/bareos hook script that looks for the interface coming online and (re)starting bareos on demand dynamically as needed. | 02:12 |
| systemdlete | how would that work? the bareos director daemon is on the host and drives everything. It initiates backups at a certain time, per its internal scheduler. | 02:14 |
| systemdlete | would the scheme you suggest work for this case? | 02:14 |
| systemdlete | that's why I mentioned that the laptop daemon (file daemon, specifically) needs to be ready for action at any time the director attempts to connect to the laptop. | 02:15 |
| systemdlete | but maybe your idea could work, idk | 02:15 |
| systemdlete | the director daemon on some host on the network will connect to each of its clients (e.g., my laptop) and initiate a session wherein it runs a backup, restore, or any other operation supported by the architecture. | 02:16 |
| systemdlete | is there a sort of "wake on lan" feature -- is that what you mean? | 02:17 |
| systemdlete | WOL for wireless ? | 02:17 |
| systemdlete | idk | 02:17 |
| systemdlete | (that would be nice to save energy) | 02:17 |
| systemdlete | btw, I've disabled the wireless powersave function due to the issues I've been having with lost or partially lost connectivity. That has solved the problem for that. But this other issue, at hand, is due (I think) to the init script ordering. | 02:19 |
| systemdlete | I suppose I could write a script that would nudge the director daemon to start the backup, which could be run from the laptop side. But I think that sort of defeats the way bareos wants to do things. | 02:21 |
| adhoc | morning all | 02:49 |
| djph | hi adhoc | 02:50 |
| adhoc | got some apps that are deprecating python 3.7 real soon now | 02:51 |
| adhoc | so have been reading up on the path to python 3.8 | 02:51 |
| adhoc | seems this is an issue on debian10 too | 02:51 |
| adhoc | lots of reading points to just installing it by hand and doing a; make altinstall | 02:52 |
| adhoc | not so keen on that to be honest | 02:52 |
| adhoc | is there a prepackaged version of 3.8.x in a repo I'm not aware of yet ? | 02:53 |
| adhoc | =) | 02:53 |
| djph | not that I'm aware | 02:53 |
| djph | .. actually | 02:54 |
| adhoc | dang | 02:54 |
| djph | ... Devuan Chimaera is 3.9.2 ... | 02:54 |
| djph | Maybe "something" will be in backports soonish? | 02:55 |
| adhoc | ah, that might be worth a look | 02:55 |
| ShorTie | 3.9.6 is latest | 02:55 |
| adhoc | is Chimaera released? | 02:56 |
| adhoc | djph: is there any doco on adding backports? I can find anything.. | 02:58 |
| fsmithred | python3.9 is not in backports | 02:58 |
| adhoc | fsmithred: ta ... | 02:58 |
| adhoc | hmm | 02:59 |
| fsmithred | but you would add a line for beowulf-backports that looks like your other lines | 02:59 |
| fsmithred | there are examples at devuan.org | 02:59 |
| fsmithred | there are beta installer isos for chimaera and alpha live isos | 02:59 |
| fsmithred | other than that, chimaera is mostly ready. | 03:00 |
| adhoc | mostly ... =) | 03:00 |
| djph | sorry to have been unclear -- I meant to say "maybe backports will get something newer eventually" | 03:00 |
| adhoc | djph: thanks =) | 03:00 |
| fsmithred | yeah, some of the desktop theme stuff is not quite ready | 03:00 |
| fsmithred | and documentation | 03:00 |
| fsmithred | but people who upgraded to chimaera months ago have been saying all along that it's very stable | 03:01 |
| djph | it is very nice, needed a bit of kicking in the kernel, but otherwise it was nearly flawless out of the box | 03:01 |
| adhoc | so deb http://deb.devuan.org/merged <release codename>-backports main | 03:01 |
| fsmithred | yeah | 03:01 |
| adhoc | is beowulf-backports | 03:01 |
| djph | ... and on a basically cutting-edge laptop | 03:01 |
| fsmithred | then apt-update | 03:01 |
| fsmithred | no | 03:02 |
| fsmithred | apt update | 03:02 |
| adhoc | understood | 03:02 |
| * adhoc updates | 03:02 | |
| fsmithred | apt -t beowulf-backports install <package> | 03:02 |
| adhoc | ok | 03:03 |
| fsmithred | and be selective | 03:03 |
| adhoc | so, what is the approximate time line to 4.0 being released? | 03:04 |
| fsmithred | everything that's in backports has never been tested all together | 03:04 |
| adhoc | understood | 03:04 |
| fsmithred | maybe september if we get our act together and write all the docs. | 03:04 |
| fsmithred | it's too hot to think right now | 03:04 |
| adhoc | hot?!? | 03:05 |
| fsmithred | northern hemi | 03:05 |
| * adhoc was scraping ice of the windscreen last week and now rolling mists and freezing rain this week ... | 03:06 | |
| fsmithred | I would gladly trade you some steam for some ice | 03:07 |
| * adhoc puts some in an envelope, marks "express" | 03:08 | |
| fsmithred | thanks | 03:08 |
| Xenguy | Heat wave up here too | 03:32 |
| Xenguy | Brain gradually gets fried | 03:33 |
| djph | 'gradually' ? | 03:33 |
| Xenguy | heh | 03:33 |
| Xenguy | depends | 03:33 |
| djph | :) | 03:33 |
| Xenguy | It puts you in a heat trance, kind of | 03:33 |
| Xenguy | You now feel the weight of said heat | 03:34 |
| onefang | Last month Australia had a heat wave, in the middle of winter. lol | 03:34 |
| djph | yeah, I know | 03:34 |
| Xenguy | The root problem is humidity, in this case | 03:34 |
| djph | I've lived with no AC for a long time | 03:34 |
| Xenguy | onefang, wow | 03:34 |
| Xenguy | djph, ^5 | 03:35 |
| Xenguy | djph, me too, we are fewer and fewer | 03:35 |
| djph | now that the new place has it ... ehhh, it's nice, but I kinda miss having to work to keep cool | 03:35 |
| onefang | Buuuuut, off topic. | 03:35 |
| djph | yep | 03:35 |
| Xenguy | It's like Dialup => Broadband to me | 03:35 |
| Xenguy | onefang, oh dang | 03:35 |
| djph | oops | 03:36 |
| Xenguy | #devuan-offtopic | 03:36 |
| Xenguy | logged in already | 03:36 |
| adhoc | ok, so what are the likely gotchas when dist-upgrading from beowulf to chimera ? | 03:53 |
| Xenguy | That's kind of my acid test for distros: can they handle an online upgrade gracefully? | 04:01 |
| fsmithred | adhoc, I got a conflict with libc6-dev and had to remove build-essential to get the upgrade to proceed. | 04:02 |
| fsmithred | also had to remove libgcc1 | 04:02 |
| Xenguy | Strange | 04:02 |
| adhoc | hmm | 04:03 |
| Xenguy | Managing a distro is hard, amiwrong? | 04:04 |
| fsmithred | try two | 04:04 |
| Xenguy | hah | 04:04 |
| Xenguy | That's right | 04:04 |
| Xenguy | It helps if you love (Devuan) Linux | 04:05 |
| fsmithred | I also had to install a couple of things as <package>=<version> | 04:05 |
| Xenguy | uh boy, that's beyond me | 04:05 |
| fsmithred | adhoc, you might not have some of the packages that gave me trouble. | 04:07 |
| fsmithred | and I did it a month ago. Some things may have changed. | 04:07 |
| adhoc | I don';t think I have pinned any package versions like that on this machine | 04:07 |
| adhoc | fsmithred: good to know =) | 04:08 |
| fsmithred | I should try upgrading a default beowulf install | 04:08 |
| fsmithred | now that I think of it, beowulf to chimaera was easier than ascii to beowul | 04:08 |
| fsmithred | f | 04:08 |
| adhoc | that is good to hear, I have moved a bunch of my machines from ascii to beowulf | 04:09 |
| adhoc | all headless machines inthe back room =) | 04:09 |
| fsmithred | for ascii to beowulf, I know there were a few times when I had to use apt, aptitude and apt-get | 04:09 |
| adhoc | there were a few issues with custom perl packages I'd messed with | 04:09 |
| fsmithred | upgrade to chimaera was just apt | 04:10 |
| Xenguy | apt-get, please | 04:10 |
| Xenguy | 8 -D | 04:11 |
| adhoc | is apt the normal thing now ? | 04:11 |
| Xenguy | Get off of my lawn | 04:11 |
| * adhoc generally only uses apt-get | 04:11 | |
| Xenguy | adhoc, Seems like it's trending that way | 04:11 |
| adhoc | apt-cache | 04:11 |
| fsmithred | apt is supposed to be the preferred command now | 04:11 |
| * adhoc blames ubuntu =P | 04:11 | |
| Xenguy | I like apt-get, traditional toolchain, yada yada | 04:11 |
| fsmithred | but it's not finished | 04:11 |
| Xenguy | fsmithred, I disagree | 04:11 |
| Xenguy | Who says "suppose" | 04:11 |
| fsmithred | pipe the output to grep and you get a warning that it might change. | 04:12 |
| adhoc | fsmithred: i'll build some beowulf machines over the weekend and then upgrade to see what is likely to be affected | 04:12 |
| Xenguy | huh | 04:12 |
| fsmithred | Xenguy, I think debian says it somewhere | 04:12 |
| fsmithred | I don't recall where I saw it. It was long ago. | 04:13 |
| Xenguy | fsmithred, Yeah, but we agree that there are some design decisions of Debian that we don't like so much | 04:13 |
| fsmithred | lol | 04:13 |
| Xenguy | oops | 04:13 |
| adhoc | Xenguy: that is why we are here, right ? | 04:14 |
| Xenguy | I think it is | 04:14 |
| Xenguy | We saw systemd, and went: hrmmmmmmmmmmmmmm | 04:14 |
| fsmithred | g'night folks | 04:15 |
| adhoc | Xenguy: that is the polite version, yes. | 04:15 |
| adhoc | fsmithred: laters | 04:15 |
| Xenguy | o/ | 04:15 |
| fsmithred | and no "d" talk in here | 04:15 |
| Xenguy | adhoc, yes | 04:15 |
| Xenguy | hah | 04:16 |
| xrogaan | anybody using chimaera, elogind and xfce4? | 19:26 |
| xrogaan | Apparently, xflock4's behavior is bugged on my end. | 19:26 |
| hagbard | xflock4 is merely a wrapper script that doesn't do anything by itself. | 19:28 |
| xrogaan | from xfce4-session amd64 4.16.0-1+devuan1 | 19:28 |
| xrogaan | well, it forks itself to death | 19:29 |
| xrogaan | ah, found the issue | 19:30 |
| xrogaan | $ xfconf-query -c xfce4-session -p /general/LockCommand | 19:30 |
| xrogaan | xflock4 | 19:30 |
| xrogaan | the script call itself | 19:30 |
| hagbard | try the locker of lightdm, if you have lightdm anyways: light-locker-command --lock | 19:30 |
| xrogaan | how do we edit those values anyway? | 19:31 |
| xrogaan | Another gnome bullshit, to do away with config files | 19:31 |
| hagbard | its not the config bulshit from gnome, but xfce4 own | 19:32 |
| xrogaan | same spirit. | 19:32 |
| brocashelm | i haven't used xflock4 in years because it's always caused problems. a better alternative would be something like i3lock | 19:32 |
| hagbard | you can find it in the settings editor in xfce4-session | 19:32 |
| xrogaan | what editor? | 19:33 |
| hagbard | Again, xflock is a mere tiny shell script, that starts whatever locker you have configured | 19:33 |
| hagbard | xfce4-settings-manager | 19:34 |
| xrogaan | There is nothing in there to change that value. I need to access xfconf | 19:34 |
| hagbard | oops xfce4-settings-editor its is | 19:35 |
| hagbard | *it is | 19:35 |
| hagbard | Channel xfce4-session | 19:35 |
| hagbard | Property LockCommand | 19:35 |
| xrogaan | fork bomb again | 19:36 |
| hagbard | What have you set LockCommand to? | 19:38 |
| xrogaan | I told it already, it's xflock4 | 19:38 |
| xrogaan | reset it to default | 19:38 |
| xrogaan | which is empty | 19:38 |
| hagbard | Set it to the locker you want to use | 19:39 |
| xrogaan | or empty | 19:39 |
| hagbard | So you don't want to lock at all? | 19:40 |
| xrogaan | it'll use the defaults | 19:40 |
| xrogaan | if the cmd is empty, it defaults to xfce4-screensaver-command --lock | 19:40 |
| hagbard | yes | 19:40 |
| xrogaan | but the lock command was set to itself. | 19:41 |
| xrogaan | problem solved! | 19:41 |
| hagbard | good | 19:41 |
| Walex | probably the only reliable screenlocker is 'xscreensaver', I would not trust others. | 20:15 |
| jonadab | I know that the person who wrote xscreensaver, has repeatedly waxed sarcastic about some of the other ones, notably the Gnome one. | 20:19 |
| jonadab | And security issues were a key aspect of his criticism. | 20:19 |
| onefang | If only xscreensaver would actually turn off my monitors like I told it to. Only seems to work the first time after reboot. | 20:39 |
| xrogaan | Anyhow, opened an issue: https://gitlab.xfce.org/xfce/xfce4-session/-/issues/120 | 20:41 |
| mason | onefang: That fails for me too. | 20:42 |
| mason | onefang: Rather, it fails erratically. | 20:42 |
| mason | If I call xscreensaver-command -activate, I'll never see DPMS sleep. If it times out on its own, it starts DPMS sleep as configured. | 20:43 |
| xrogaan | you can troubleshoot by setting `xscreensaver.verbose:true` and `xscreensaver.logFile:/path/to/file.log` in your $HOME/.Xresources file | 20:45 |
| xrogaan | then consult the log to see what's happening. | 20:45 |
| mason | xrogaan: Oh, didn't know about that. Will do. | 21:27 |
| xrogaan | or run xscreensaver -verbose | 21:30 |
| xrogaan | and -log filename | 21:31 |
| mason | Already going via resources. I'm fond of using X resources for config. | 21:31 |
| mason | xrogaan: Fascinating stuff: https://bpa.st/RCMQ | 22:17 |
| mason | xrogaan: I think the even at 16:08 was where the DPMS was supposed to kick in but didn't, so it respawned the process doing the visuals (deco) | 22:18 |
| xrogaan | I don't know. | 22:29 |
| mason | Neither do I. I've collected the whole log and shipped it off to jwz, and we'll see if *he* knows. | 22:34 |
| xrogaan | okay, that website is cool: https://www.jwz.org/. | 22:57 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!